AI 辅助编程工作流收藏
AI 编码助手在 X 上讨论热度极高。以下为跨多条高互动线程的共识提炼（非产品广告）。
有效分工
| 人类负责 | AI 适合 |
|---|---|
| 需求与边界 | 样板代码、测试骨架 |
| 架构取舍 | API 用法查文档式问答 |
| 安全与合规 Review | 正则、数据转换 |
| 最终合并签字 | 多方案对比草稿 |
「规格先行」派
一派强调：先写 Markdown 规格 + 验收标准，再让 AI 生成实现。收益是减少「看起来能跑但不对」的 diff。与本博客 VitePress + Git 工作流天然契合。
测试派反击
另一派要求 AI 必须先给 failing test，再写实现——类似 TDD 加速器。对 Flutter Widget 测试、Go table-driven test 均有人分享模板。
Review 清单（社区版）
- 是否引入未知依赖或许可证风险
- 是否硬编码密钥样式字符串
- 错误处理是否吞异常
- 并发是否共享可变状态
- 生成代码是否超过需求范围（scope creep）
何时拒绝 AI
讨论里反复出现的红线：
- 密码学实现
- 复杂并发与资金相关逻辑
- 不熟悉框架的「整库生成」
长期技能变化
工程师价值被描述为向 问题分解、验证与沟通 迁移——与「只会写语法」形成对比。收藏此帖的意义，是提醒自己：工具变快，判断力不能外包。
建议把本帖当检查表，贴在 PR 模板旁，而不是当真理。