AI编码落地
团队卡点
- 需求本来就模糊，AI 只会把模糊放大。
- 没有清晰的项目规范、代码约定和架构边界，AI 的生成只会越来越散。
- 团队如果说不清楚“谁对结果负责”，AI 最后一定会变成甩锅工具。
- 哪些任务适合让 AI 参与，哪些任务必须人工主导，如果没有边界，效率和风险都会一起失控。
实践实施
- 样板代码、单元测试、文档整理、数据转换脚本、常规页面和表单。
- 任务结构清晰、风险可控、容易 review，适合标准化。
- 高重复、低风险跑顺，逐步往复杂场景延伸，不建议最核心、最敏感的部分开始
无需一开始就制定复杂、繁重的规范，但要达成一些最低共识
- AI生成的代码能否直接提交？
- 哪些模块必须由人工主导开发？
- 哪些场景只允许AI辅助？
- 评审时如何检查AI产出的内容？
- 规范无需繁琐，但必须明确，才能避免混乱。
- 把知识沉淀成AI能读懂的上下文资产，AI就能摆脱从零开始的困境，更好地贴合团队需求。
- 项目说明、代码规范、架构约定、业务术语、常见模板、历史设计决策、评审检查清单等内容
- 从个人摸索走向团队共识
- 从零散提问走向上下文管理
- 从局部提速走向整体流程优化
- 从AI 帮我写代码走向AI被接进交付体系
AI的边界
- AI实现逻辑，但不能为设计决策负责
- 上下文窗口再大，也不是真正的记忆
不要指望 AI 真正承担长期连续的项目记忆,主动管理上下文，仍然是人的责任。
- 前面说好的约定，后面忘了
- 早期设计思路，后面偏了
- 对话一长，模型开始自相矛盾
- 一旦换会话，很多东西又得重新解释
- 涉及金钱的核心逻辑：比如支付、结算、对账、计费、退款。
- 安全和认证相关代码：比如密码存储、权限校验、Token 验证、加解密。
- 合规和审计相关功能：比如隐私数据处理、日志留存、数据访问控制。
- 高风险领域的关键功能：比如医疗、航空、军工、自动驾驶、高危工业控制。
真正决定质量的，不只是代码实现，而是业务逻辑、系统设计和长期维护成本。
- 核心业务算法
- 公共库和基础框架性能
- 敏感、长期维护的底层代码
- 放心交给AI
- 样板代码
- 常规 CRUD
- 单元测试初稿
- 文档和注释
- 一次性脚本
- 查资料、比方案、做探索