autonomous-development

Category: Development & Coding | Uploader: taichuy | Downloads: 0 | Version: v1.0（Latest）
用于用户要求 AI 作为持续迭代开发者，按 7Flows 的工程观自主评估项目阶段问题、选择单轮最高优先级任务并推进主链闭环时使用。
Changelog: Source: GitHub https://github.com/taichuy/7flows
Directory Structure

Current level: .agents/skills/autonomous-development/
📁 references/
- 📄 engineering-rubric.md 10.6 KB
- 📄 session-bootstrap-prompt.md 7.1 KB
📄 SKILL.md 6.1 KB
SKILL.md

---
name: autonomous-development
description: 用于用户要求 AI 作为持续迭代开发者，按 7Flows 的工程观自主评估项目阶段问题、选择单轮最高优先级任务并推进主链闭环时使用。
---

# 7Flows 自治开发

## 何时使用

当任务涉及以下任一场景时使用：

- 用户明确要求“持续自治开发”“自主推进项目”“自己判断优先级并实现”
- 需要在多个候选方向里判断本轮最值得做的主题，而不是只执行一个明确的小改动
- 需要判断当前是该补功能闭环、补运行基础、消除阻塞型架构问题，还是只需要轻量整理

不要用于：

- 用户已经明确指定了单一、局部且边界清楚的任务
- 纯 brainstorm、纯观点讨论，尚未进入可执行落地阶段

## 先建立哪些事实

至少复核：

- `AGENTS.md`
- `docs/product-design.md`
- `docs/technical-design-supplement.md`
- `docs/open-source-positioning.md`
- `docs/dev/team-conventions.md`
- `git status --short`

如当前本地开发者需要衔接自己的稳定偏好、近期判断或最近几轮个人过程记忆，可再查看：

- `docs/.private/user-preferences.md`
- `docs/.private/runtime-foundation.md`
- `docs/.private/history/`

若任务进入具体领域实现，再组合对应领域 skill：

- 后端：`backend-code-review` / `backend-testing`
- 前端：`frontend-code-review` / `frontend-testing` / `component-refactoring`
- 收尾：`development-closure`

## 核心原则

- 自治不是“自由发挥”，而是按 7Flows 已确认的工程观和当前事实，选择本轮最高杠杆任务。
- 目标不是做局部美化，而是推进项目整体完整度、主链路闭环和长期可演进性。
- 先判断阶段问题，再决定做什么；不要先挑自己擅长或做起来舒服的任务。
- 如当前本地开发者维护了 `docs/.private/runtime-foundation.md`，先比较当前用户输入与目标账本是否一致；一致时默认从其中最高优先级未完成项中选题，不一致时先和用户确认是改主目标还是新增附加目标。
- 如果方向仍有多种现实可行路径，先基于代码事实列出候选方案、好处、代价与推荐方案，再进入实现。
- 单轮只推进一个主主题，最多附带一个为主主题服务的结构调整。
- 架构不是目的；只有当架构问题已经阻塞当前 `P0 / P1` 主线时，才优先处理架构。
- 文件拆分不是目的；只有当职责混杂、变更传播过大、检索维护困难，或已经同时影响人类与 AI 修改效率时，才做解耦。
- 任务规划不要切得过细；优先先打通完整模块或链路闭环，再根据测试与回归结果修复剩余问题。
- 给自治开发模型的会话提示词应保持“少量高质量原则 + 明确优先级 + 明确禁止项 + 固定复盘格式”；不要把所有细则都塞进启动提示词里。

详细的“好项目 / 好代码 / 好架构 / 坏信号 / 单轮评分规则”见 `references/engineering-rubric.md`；适合每次新会话开头直接使用的循环提示词见 `references/session-bootstrap-prompt.md`。

## 单轮决策流程

### 1. 先判断当前阶段问题

至少按四层复核：

- 用户层：主链路是否更完整，作者 / operator / 调用方是否更容易完成关键动作
- AI 与人协作层：运行事实、排障入口、续跑与解释是否更统一
- AI 治理层：敏感访问、执行隔离、审计、发布边界是否更诚实
- 运行基础 / 发布 / 兼容层：runtime、publish、compat、sandbox readiness 是否更接近统一主链

并在开始实现前先形成一份“愿景目标完整度”快照，至少回答：

- 哪些关键层已经有稳定骨架
- 哪些层已经形成最小闭环
- 哪些层仍是当前全局最大缺口
- 本轮若成功，会推动哪一层完整度前进

如果存在本地目标账本，还要额外回答：

- 当前用户输入是否与已记录目标一致
- 如果不一致，这是临时子任务、附加目标还是主目标漂移
- 是否需要先向用户确认再更新本地记录

### 2. 再生成候选任务

候选任务默认来自：

- 当前本地开发者私有 `runtime-foundation.md` 的当前 `P0 / P1` 与优先级（如存在）
- 当前代码里的真实阻塞热点
- 与本轮主题直接相关的文档或 skill 漂移

不要把“可以做”自动当成“现在最该做”。

### 3. 用工程 rubric 选题

- 先看它是否推进主链闭环
- 再看它是否消除后续开发阻塞
- 再看它是否增强共享能力边界、可靠性或安全性
- 最后才看美观度、命名整洁度或局部一致性

若一个候选任务主要只是：

- 样式整理
- 表层抽象
- 无明确业务收益的大重构
- 与当前 `P0 / P1` 主线无关的局部修补

默认不优先。

## 执行约束

- 先复用现有结构、helper、service 边界和 skill，不从零再造流程。
- 不重开已经在产品 / 技术基线中定下的边界，除非代码事实已经明显冲突。
- 若工作区已有无关脏改动，默认避开；若必须进入同一区域，先理解现状再继续，不覆盖未知变更。
- 改动应尽量形成“下一轮可继续接”的稳定中间态，而不是只留下半成品抽象。

## 收尾要求

- 如果本轮形成 durable change，收尾时必须组合 `development-closure`
- 共享规则或入口变化时，同步更新 `docs/dev/team-conventions.md`、`AGENTS.md`、相关 skill、索引入口或 `docs/adr/`
- 如果当前开发者确实需要本地连续性，再把稳定偏好、当前优先级或过程留痕写入 `docs/.private/user-preferences.md`、`docs/.private/runtime-foundation.md` 与 `docs/.private/history/`
- 最终汇报必须显式包含“愿景目标完整度”视图，帮助后续判断当前整体阶段与剩余关键缺口

## 常见反模式

- 把“自治”理解成每轮都重新发明产品方向
- 长时间困在局部修补、样式整理或抽象洁癖里
- 用“先做架构”回避真实的主链闭环问题
- 没有依据当前代码事实和当前开发者本地优先级索引（如存在），只凭泛化经验选题
- 明明是多模块阻塞，却继续在单点上打补丁
Comments 0
Latest | Hot
Please login before commenting.
No comments yet. Be the first one!
autonomous-development

Directory Structure

SKILL.md

Report

Notice
