AutoDev Mode 是一个面向编码代理的自主开发工作流技能。它的目标是把用户的一句话需求转化为可执行、可验证、可复盘的软件开发过程。
与普通的“问一步、做一步”模式不同，AutoDev Mode 强调代理主动完成项目探索、方案发散、外部参考调研、任务规划、代码实现、验证检查和最终报告。它适合用于中高复杂度的软件改进任务，例如产品体验优化、前端改版、架构整理、开发流程提升、功能完善和代码质量增强。
核心原则是：
用户给出目标，代理负责探索、研究、规划、执行、验证和汇报。
AutoDev Mode 不是一个单纯的提示词模板，而是一套带有阶段、边界和验证要求的开发协议。它帮助编码代理在开放式任务中保持主动性，同时避免失控修改。
这个技能特别适合以下场景：
- 用户只给出一句较宽泛的目标，例如“让这个项目更成熟”“优化这个聊天应用”“参考 GitHub 上的类似项目改进这个功能”。
- 任务需要代理自动拆解，而不是等待用户逐步指挥。
- 任务需要结合项目现状、外部项目参考和最佳实践。
- 任务预计会涉及多轮文件扫描、设计判断、代码修改和验证。
- 用户希望在执行过程中看到清晰进度，而不是只在最后得到结果。
AutoDev Mode 不适合简单的一行修复、纯问答、无代码动作的问题，或未经授权的破坏性操作。
很多软件任务并不是从明确规格开始的。用户往往只知道“想让项目更好”，但还没有完整拆解方案。AutoDev Mode 用固定阶段把模糊目标转化为工程动作：
- 解释目标
- 明确范围
- 探索项目
- 发散方案
- 调研外部参考
- 对比可复用模式
- 制定计划
- 小步实现
- 验证结果
- 复盘质量
- 汇报进展
- 沉淀经验
这让代理能在目标不完整时继续前进，同时保持可追踪性。
AutoDev Mode 鼓励代理主动探索和执行，但不允许无控制地修改项目。它明确划分了可自动执行和必须询问用户的操作。
代理可以自动完成：
- 扫描项目文件
- 阅读相关代码
- 搜索 Web 和 GitHub 参考
- 头脑风暴改进方向
- 编写计划
- 做小范围本地补丁
- 运行测试、构建和浏览器验证
代理必须先获得用户确认：
- 删除用户数据或文件
- 执行破坏性命令
- 安装依赖
- 修改数据库 schema
- 发布、部署或推送到 GitHub
- 进行超出当前目标的大型重构
- 直接复制外部代码
这种设计让自动化更实用，也更安全。
AutoDev Mode 要求在合适任务中主动参考外部项目和文档。尤其当用户提出“参考 GitHub”“最佳实践”“类似产品”时，调研不是可选步骤。
它要求代理记录：
- 参考项目名称
- 项目 URL
- 活跃度或可信度信号
- 可学习的设计或架构模式
- 对当前项目的适用性
同时，技能明确要求“提取模式，而不是盲目复制代码”。这避免了许可证风险和不适配问题。
AutoDev Mode 把开发任务分为四个级别：
| 等级 | 名称 | 适用任务 | 规划方式 |
|---|---|---|---|
| L1 | Fix Mode | 小 bug、CSS、文案修复 | 不写计划，直接定位、修改、验证 |
| L2 | Build Mode | 范围清楚的小功能 | 轻量计划 |
| L3 | AutoDev Mode | 一句话宽泛目标 | 头脑风暴、调研、计划、执行 |
| L4 | Architecture Mode | 大型重构或系统设计 | 文件计划、技术 spike、分阶段执行 |
这个分级避免了两个常见问题：
- 小任务被过度流程化
- 大任务没有足够规划就开始修改
AutoDev Mode 的标准流程包含 12 个阶段。
代理先把用户的一句话需求转化为明确的工程目标，避免后续动作偏离方向。
代理识别约束、风险标签、成功标准，以及哪些动作需要用户批准。
代理扫描项目结构、技术栈、入口文件、测试命令、状态管理、持久化路径和相关模块。
代理至少提出 5 个改进方向，并按照 P0、P1、P2 排序。
代理搜索 Web、GitHub、文档和类似产品，寻找可复用的设计、架构和测试模式。
代理把外部参考转化为当前项目可用的设计判断，而不是机械复制。
代理把优先级最高的 P0/P1 任务拆成小步，标注涉及文件、风险和验证方式。
代理一次只实现一个小任务，避免批量修改造成回滚困难。
代理根据风险标签运行测试、构建、浏览器检查、状态检查或持久化检查。
代理进行规格复查、代码质量复查、用户体验复查、安全复查和 diff 复查。
代理总结完成内容、验证证据、限制和下一步建议。
当发现可复用经验时，代理可以把它沉淀为技能或更新现有技能。
AutoDev Mode 的一个重要设计是风险驱动验证。不同类型的改动需要不同的验证证据。
| 风险标签 | 需要验证的内容 |
|---|---|
| UI | 浏览器打开、真实点击流程、控制台错误、布局溢出、移动端表现 |
| State | 初始状态、修改状态、保存状态、刷新后状态、边界状态 |
| Persistence | 正确存储键、数据隔离、旧数据兼容、探测数据恢复 |
| Security | 无密钥泄露、权限边界不变、外部代码许可证检查 |
| Performance | 无明显昂贵循环、无渲染风暴、大数据路径已考虑 |
这套验证方式让代理不能只说“完成了”，而要说明“如何证明完成了”。
AutoDev Mode 要求代理在工作过程中持续提供简短状态块，例如：
## AutoDev Status
目标：优化聊天应用体验
模式：L3 AutoDev
当前阶段：Research
进度：3/12
阻塞：无
下一步：对比 GitHub 参考项目中的会话管理模式
[x] Interpret
[x] Explore
[>] Research
[ ] Plan
[ ] Execute
[ ] Verify这种进度格式适合长任务，可以让用户知道代理当前在做什么、已经完成什么、下一步是什么。
| 维度 | 普通模式 | AutoDev Mode |
|---|---|---|
| 目标处理 | 依赖用户逐步说明 | 主动解释并拆解目标 |
| 项目探索 | 可能只看局部文件 | 系统扫描相关结构 |
| 方案设计 | 直接实现常见方案 | 先发散，再排序 |
| 外部参考 | 可选 | 在相关任务中强制调研 |
| 实现方式 | 可能批量修改 | 小步 patch |
| 验证 | 可能只跑测试 | 按风险标签验证 |
| 汇报 | 总结修改 | 总结目标、证据、限制、下一轮建议 |
| 安全边界 | 依赖代理判断 | 明确规定审批边界 |
用户可以这样触发 AutoDev Mode：
让这个项目更成熟。
参考 GitHub 上类似项目，优化这个聊天应用的会话体验。
帮我自动分析这个项目还能改进哪些地方，并先实现最重要的一项。
把这个前端工具做得更像一个可发布产品。
如果要把 AutoDev Mode 作为一个公开技能仓库发布，可以采用以下结构：
autodev-mode/
├── README.md
├── SKILL.md
├── LICENSE
└── examples/
├── simple-fix.md
├── product-improvement.md
└── github-reference-workflow.md
建议 README 包含：
- 技能简介
- 适用场景
- 工作流阶段
- 安全边界
- 示例提示词
- 验证矩阵
- 许可证说明
当前 AutoDev Mode 的设计已经具备较完整的工程闭环：
- 有明确适用范围
- 有任务分级
- 有阶段化流程
- 有风险标签
- 有验证矩阵
- 有进度汇报格式
- 有外部研究规则
- 有审批边界
它的优势是把“自主开发”从一个模糊概念落到了可执行流程上。对于 Codex、Claude Code、Cursor Agent 或其他编码代理来说，这类技能可以显著提升长任务执行的一致性。
后续可以继续增强以下方面：
- 增加更多真实案例
- 提供英文版 README
- 加入完整的 GitHub 发布模板
- 增加不同技术栈的验证清单
- 增加失败案例和反模式说明
- 增加与 Issue、PR、CI 工作流的衔接示例
- 修正文档中可能存在的字符编码问题
建议将这个技能定位为：
A structured autonomous development workflow for coding agents.
中文定位可以写成：
面向编码代理的结构化自主开发工作流。
GitHub 仓库描述建议：
AutoDev Mode is a structured workflow skill that helps coding agents turn one-sentence goals into scoped, researched, planned, implemented, verified, and reported software changes.
中文简介建议：
AutoDev Mode 是一个面向编码代理的自主开发技能，用于把一句话需求转化为可规划、可执行、可验证的软件开发流程。
AutoDev Mode 的核心价值不是“让代理更大胆”，而是“让代理在复杂任务中更有方法”。它通过任务分级、阶段流程、外部研究、风险验证和审批边界，把自主开发变成一个可观察、可控制、可复盘的工程过程。
如果发布到 GitHub，它可以作为一个通用的 Agent Skill、编码代理工作流模板，或团队内部 AI 开发规范的基础版本。