为什么现在值得做
我们先不谈模型能力，先看研发日常。
前后端同事每天真正花时间的地方，很多并不是业务判断本身，而是这些动作：
- 找代码入口
- 看调用链
- 补样板代码
- 查错误日志
- 写测试
- 写 PR 描述
- 在 IDE、终端、代码平台、文档平台之间切换
这些事情单看都不难，但它们会不断打断主线任务。GitHub 的开发者反馈里有一个判断很值得借用：好的 AI 工具，最直接的价值不是替代开发者，而是减少上下文切换，帮开发者把判断权留下来。
以后这些打断型动作，尽量先交给 AI 处理。
先试什么
不要一开始就挑战最高难度。第一波试点一定要选那些"能看懂结果、能快速验证、风险可控"的任务。
前端适合先试的场景
- 解释路由、页面状态流和调用链
- 根据已有页面模式补组件骨架、请求层和类型
- 生成复杂页面的回归清单
- 根据已有改动生成 PR 摘要和风险说明
后端适合先试的场景
- 解释 controller、service、repository 之间的数据流
- 根据已有模式补 handler、DTO、校验和单测
- 排查接口异常、事务问题、序列化问题
- 生成接口文档、迁移说明和回滚说明
第一波不要硬推的场景
- 没有测试兜底的核心模块重构
- 权限、安全、资金链路的自动改动
- 一次跨多个系统的大范围联动修改
- 需求和完成标准还没讲清楚的任务
Vercel 的经验很明确：当前最容易成功的 agent 场景，仍然是低认知负担、高重复、流程稳定的工作
主流程
下面这一段，是最核心的内容。
第一步：定义任务
任何任务开始前，先把输入补齐。最少要有四段：
GoalContextConstraintsDone when
这一步的作用非常简单，就是减少 AI 自己脑补。Codex 官方把这四段结构明确当成默认输入方式。
如果人自己都讲不清楚要改什么，就不要期待 AI 能稳定地改对。
第二步：计划分析
复杂任务先进入 Plan Mode，只读分析，不直接改代码。涉及以下情况时，这一步不要省：
- 多文件改动
- 跨模块联动
- 缓存、权限、事务、状态管理
- 老代码重构
- 构建链路或数据库变更
这一阶段只要求 AI 回答三件事：
- 影响范围是什么
- 风险点是什么
- 验证方式是什么
如果这三件事说不清楚，就先别进入实施。
第三步：小步实现
编码阶段不要追求"这一轮全部做完"，而是要追求"这一轮做一个清晰子任务"。比如：
- 只补一个 store 的持久化
- 只修一个接口错误分支
- 只补一组单测
- 只改一个页面请求链路
不是 AI 一次改得越多越厉害，而是一次改得越清楚越可靠。
第四步：自检验证
代码改完先别急着 commit。先让 AI 交代清楚：
- 改了哪些文件
- 为什么改这些文件
- 还缺哪些验证项
- 风险最高的是哪里
然后跑最小测试集、最小 lint 或最小类型检查。Simon Willison 也提到，coding agent 表现稳定的关键，往往是自动化测试、开发服务器、lint、类型检查和更详细的错误信息，而不是把 prompt 写得越来越长。
第五步：人工 Review
AI 可以把 review 前移，但不能替代最终 review。这里最建议统一一个最小 review 口径：
- 是否符合仓库规则
- 是否复用了已有模式
- 是否引入重复实现
- 是否有高风险但未验证的改动
- 是否补齐必要说明
第六步：Git 提交与 PR
到了这一步，AI 最适合帮忙做的是：
- 生成 commit message 候选
- 生成 PR 标题
- 输出变更摘要
- 列出影响范围
- 写验证方式
- 写风险与回滚点
第七步：复盘沉淀
如果一类任务反复出现，就不要每次重新口述，而要开始沉淀：
- 规则文件
- hooks
- skills
- review 清单
- 自动化流程
这一步不是附属动作，而是团队 AI 收益能不能累积的关键。
关键功能应该怎么讲
这部分最容易讲乱，因为名词很多。建议你不要按产品介绍，而是按"这些功能分别解决什么问题"来讲。
规则文件
规则文件本质上是给 AI 的长期说明书，最适合放：
- 项目结构
- 启动命令
- 构建与测试命令
- 命名和编码规则
- review 要求
- 禁止事项
规则文件就是把"大家默认知道的事"写成"AI 每次都会先知道的事"。
Plan Mode
Plan Mode 只适合做一件事：先理解，再动手。它不是拖慢速度，而是在减少返工。
MCP
MCP 不负责写代码，它负责给 AI 提供仓库外的真实信息，比如：
- PR
- Issue
- 日志
- 监控
- 接口文档
- 知识库
能让 AI 去读事实，就不要让它靠聊天记录猜事实。
Hooks
Hooks 解决的是"哪些动作必须自动执行"(门禁系统)。
例如：
PreToolUse拦截危险命令PostToolUse自动格式化PermissionRequest管高风险操作SessionStart提醒先读规则Stop做任务结束检查
规则文件告诉 AI 应该怎么做，hooks 负责把一部分动作变成必须做。
并行会话和 git worktree
当团队同时做功能开发、线上 bug、重构探索时，最容易出问题的不是模型能力，而是上下文串线。这里建议直接强调两个原则：
- 一任务一会话
- 一高风险任务一 worktree
Skills 和 Automations
如果某类动作已经反复出现，就先做成 skill；如果它已经稳定到不太需要人干预，再做 automation。
Git 落地
新功能
对应命令：
bash
git switch main
git pull --ff-only
git switch -c feat/xxx每完成一个子任务，小步提交：
bash
git status
git diff --stat
git add src/a.ts src/b.ts
git commit -m "feat(scope): summary"提交前让 AI 审查暂存区：
md
请审查当前暂存区改动：
1. 说明改动目的
2. 指出潜在风险
3. 列出还缺的验证项
4. 建议 commit messageBug 修复
Bug 修复时最重要的是复现步骤。
没有复现步骤，就不要期待 AI 稳定修好问题。
示例：
md
Bug：保存成功后刷新页面状态丢失。
复现步骤：
1. 启动项目
2. 进入设置页
3. 打开开关
4. 点击保存
5. 刷新页面
要求：
- 先复现
- 先找根因
- 修复后运行最小相关测试
- 输出验证步骤并行任务
如果团队要同时跑功能、bug 和重构，建议直接上 git worktree：
bash
git worktree add ../project-bugfix -b fix/bug-x main
git worktree add ../project-refactor -b refactor/module-y main它的价值：
- 上下文不串
- 分支不串
- 改动不串
回滚
共享分支优先用：
bash
git revert <commit_sha>不要把最危险的命令直接交给 AI。更适合让 AI 做的是：
- 找问题 commit
- 分析影响范围
- 列回滚后的验证清单
自动化作为第二阶段
自动化不是第一波要做的事。第一波只解决"仓库内流程跑顺"，第二波才解决"稳定动作自动化"，第三波再做"跨系统自动化"。
怎么理解分层
Codex/Claude Code：编码执行层Hermes Agent：自动化调度层dws/lark-cli：协同执行层
也就是说：
- 写代码、跑测试、做 review，还是交给擅长代码的 agent
- 长期运行、定时任务、跨平台分发，可以交给
Hermes Agent - 真正落到钉钉、飞书的消息、日历、待办、文档、会议，再交给官方 CLI 去执行
例如：
Hermes Agent定时扫描最近合并的 PR- 调用
Codex或Claude Code生成变更摘要和风险项 - 再通过
dws或lark-cli发到研发群、写待办或生成周报提醒
前后端团队先把代码内工作流跑顺，再考虑跨系统自动化，成功率会高很多。
收尾
团队真正需要统一的，不是"大家都用哪个模型"，而是"大家按照什么顺序把 AI 接入现有工程流程"。
定义任务 -> 计划分析 -> 小步实现 -> 自检验证 -> 人工 review -> Git 提交与 PR -> 复盘沉淀 -> 再逐步自动化
只要这条顺序跑顺，AI 带来的收益就不只是"写得更快"，而是：
- 找代码更快
- 改动更稳
- review 更清晰
- 提交更规范
- 信息同步成本更低