AI Coding 工作流

AI Coding 的产出不是“模型写了一段代码”，而是一个工程师能够解释、测试、回退并交给同事审查的变更。工具会更新，稳定的工作流不会：先确认结果，再理解仓库，然后小步实现、验证和提交证据。

---

一条可靠的开发闭环

任务结果与边界
  → 读取仓库规则
  → 定位现有实现与相邻模式
  → 写计划和验收条件
  → 建立失败基线
  → 实现最小 vertical slice
  → 单测 / 集成 / UI 或真实客户端验证
  → 审查 diff 与安全边界
  → scoped commit + evidence

---

按任务形态选工作界面

不要把工具品牌当能力边界。先看任务需要什么交互方式：

Cursor、Claude Code、Codex、Kiro 等产品都可能覆盖多个界面。具体能力和价格会变化，页面不应把某个产品固定描述为永久“最适合”。

---

开工前的 Task Brief

## Outcome

登录失败时，用户看到可恢复的错误提示，不再出现空白页。

## In scope

-   登录表单错误状态
-   401/429 的用户提示
-   对应单元测试和浏览器回归

## Out of scope

-   更换认证 provider
-   修改现有 URL
-   重做整个登录页视觉

## Constraints

-   保留现有 API contract
-   使用仓库已有 request/error helper
-   不记录密码或 token

## Acceptance

-   错误密码返回明确提示
-   429 告知稍后重试
-   刷新后可再次提交
-   相关测试和真实浏览器流程通过

“修一下登录”会迫使 Agent 猜目标、边界和终点。Brief 不是写长 PRD，而是把不可猜的决定写清楚。

---

先探索，再允许修改

第一轮只读检查应包括：

pwd
rg --files -g 'AGENTS.md' -g 'CLAUDE.md' -g 'README.md'
rg -n "login|signIn|401|429" src
git status --short
git log -5 --oneline

要求 Agent 回答：

1. 当前数据路径是什么？
2. 最接近的已实现模式在哪里？
3. 哪些用户改动必须保留？
4. 哪个测试最能重现问题？
5. 这次修改会不会触碰 URL、权限、数据库或外部发布？

没有定位证据就开始写代码，通常会产生重复 utility、错误目录或覆盖并行工作。

---

Plan 只需要覆盖风险

一个可执行计划应该是 vertical slice，而不是“分析、编码、测试”三句废话：

1. 在 request error mapper 中保留 401/429 类型
2. 登录表单根据错误类型显示可恢复文案
3. 为 mapper 添加边界测试
4. 在浏览器执行错误密码与 rate-limit 两条流程
5. scoped stage，仅提交本次文件

每一步都应有完成信号。若计划会改变公开 URL、删除数据、发送消息或部署生产，需要停下来获得明确授权。

---

小步实现与验证

建议节奏：

修改一个行为
  → 跑最窄测试
  → 查看 diff
  → 修复或继续
  → 完成 vertical slice
  → 跑更高层验证

测试“命令退出 0”不等于用户结果完成。验证层级要与任务终点一致。

---

Diff Review：AI 代码重点看什么

1. Scope drift：是否改了未授权模块或 URL？
2. Invented API：import、函数、配置项是否真实存在？
3. Pattern drift：是否绕过已有 helper 和设计系统？
4. Hidden side effects：是否新增写库、网络、日志或删除？
5. Error semantics：错误是否被吞掉或全变成 500？
6. Security boundary：客户端校验是否错误地替代服务端授权？
7. Test quality：测试是在验证行为，还是复制实现？

git diff --check
git diff --stat
git diff -- path/to/scoped/files
git status --short

只看 Agent 总结不够。总结可能漏掉文件，Git diff 才是变更事实源。

---

团队规则放哪里

Kiro 的 Specs 当前以 requirements、design、tasks 组织功能；Claude Code 等工具支持项目规则文件。关键不是格式名称，而是规则有明确作用域、能版本管理，并且不会每次靠口头重述。

---

用证据衡量效率

不要写未经验证的“效率提升 50%”。建立团队自己的基线：

比较前后使用相同时间窗口和任务分类。没有可比基线时，指标应标为 unavailable，不要猜。

---

高风险任务的额外闸门

• Auth、权限、计费：人先写 threat model 和业务不变量。
• Migration：先备份、dry run、抽样、回滚，不允许 Agent 直接生产执行。
• 并发与分布式锁：验证多进程/多 pod，不接受只在单进程通过。
• 删除与公开发布：解析精确目标，人工批准并读取外部终态。
• Secrets：日志、Prompt、截图和提交中都不得出现。

AI 可以帮助诊断和生成候选 patch，但责任人必须理解每个高风险变更的失败方式。

---

动手练习

选一个真实的小 bug：

1. 写 Task Brief 和 out-of-scope。
2. 让 Agent 只读探索并引用现有模式。
3. 保存修改前的失败证据。
4. 一次只实现一个行为并跑最窄测试。
5. 做 diff review，再跑真实用户流程。
6. 生成 evidence pack：文件、命令、结果、未覆盖风险和 commit。

完成标准

• 目标、边界和验收不是由 Agent 猜出来的。
• 修改前有基线，修改后有同一流程的验证。
• 我读过 scoped diff，并能解释高风险代码。
• 提交不包含其他人的工作区改动。
• 效率结论来自可比数据，不使用虚构数字。

相关阅读

• Vibe Coding 实战
• AI Rules 配置
• Claude Code Context Management
• 长任务 Agent Harness

官方参考

• https://code.claude.com/docs/en/quickstart
• https://kiro.dev/docs/specs/
• https://kiro.dev/docs/steering/