[转]一份关于 AI 编程的简明行为指南

原文地址 https://www.piglei.com/articles/a-simple-ai-coding-guide-for-engineers/

AI 编程发展迅猛，Claude Code、Codex 等 AI Agent 已成为许多软件工程师工作时必不可少的得力助手。然而，对于如何在项目中更好地实践 AI 编程，目前仍然是一副“八仙过海，各显神通”的模样。

假如同一个团队里的工程师，在如何使用 AI 工具的“大问题”上没有达成共识，就会出现协作上的摩擦，对项目产生不良影响。

因此，本文尝试面向软件工程师群体，对 AI 编程的推荐行为实践做一些总结，弱化具体的工具和技巧（比如 Spec 驱动还是不 Spec 驱动？），着眼于更通用的方面（比如初级工程师该完全委派 AI Agent 修 bug 吗？）。

内容分为“对所有人”和“对初级工程师”两部分，其中“对初级工程师”部分，针对这类人群身处的特殊阶段，提供了一些量身定制的建议。

说明：本文部分内容由 jianan、wklken 参与共创；本文观点基于笔者所身处的工作环境总结而来，不一定完全适用于其他项目，酌情采纳；

对所有人

谨记 Agent 不对代码担责

• AI Agent 是人的拓展和“分身”，不直接承担责任
• 拒绝“AI 传话人”定位，不仅是使用者，更是代码最终责任人
• Review AI 生成的代码，理解它们，不要提交自己不理解的代码
  • 如何判断自己是不是真的理解某件事？“费曼学习法”—你是否能向其他没有背景的人解释它？
• 不要过度依赖其他人（AI）在 Review 阶段对你的工作做最后把关，这是不负责任的表现

多“协作”，少“委派”

• 两种心智模型，“协作”意味着你在理解对方的基础上共同做决定，“委派”意味着你只关注最终结果
• 不要去模仿一位“产品经理”，仅用自然语言高高在上地提需求，不关注实现细节
  • ~~“怎么实现我不管，这个需求很简单！”~~
• 深入探索程序设计和整体结构，和 Agent 一起推敲出更优的答案
• 重复一次：AI 不对代码担责，也不对项目的长期可维护性负责

拆分你的 PR

• AI 写代码又快又多，很容易产出几千行改动的 PR
• 大 PR 极大增加了 Review 难度，Review 过程容易浮于表面，最终导致工程质量不可控
• 不憋“大招”，控制 PR 粒度（推荐<600行），小步快跑，分阶段交付
• 如果 PR 实在无法拆分，尽量提供 PR 的设计文档（design_notes 目录）以辅助 Reviewer 理解

说明：设计文档并不是详细到代码级别的 Spec 规格说明，而是站在更高抽象层的，供人阅读的功能“说明书”。推荐由人编写核心内容或框架，AI 可辅助补全细节。

善用 Plan 模式，多做前置探索

• 开发新需求，应当先熟悉相关模块/领域知识，了解项目当前实现等（可借助 AI 调查梳理）
• 不要在真正理解需求前，就让 AI 开始写代码
  • 重复一次：“费曼学习法”判断自己是否真正理解
• 先提问或启用 plan 模式与 AI 澄清需求（学习 AI 提示词技巧）
• 别被 AI 带着走，独立思考，怀疑主义，通过反问等方式来开拓思路
• 只有对问题有清晰的认知，才能判断 AI 的实现是否合理，而正确的判断无价

采纳稳定的库，优于 AI 从零实现

• 对于工具函数和库，比起使用第三方库，AI 有种偏向于“自己手撸”的倾向
  • 不是说“造轮子”一定不好，但是……
• 解决常见领域的成熟问题（例如 gjson），倾向让 AI 采纳库而不是自己实现
• 如何知道哪些库适合？跟 AI 聊，或自己动手查阅资料，日常积累不可少
• 多个库可用时，人判断最适合项目的（功能契合度、活跃度，未来演进等等）

创建 PR 前使用 AI Review

• 创建新 PR 前，应当使用 AI Agent review 当前改动并根据建议调整代码
• AI 前置 review 可减轻之后人工 review 的负担，提升迭代效率
• 可使用任何 review SKILL 或简单 prompt 完成

下面是一条示例 prompt：

你是一名代码评审专家。和 master 分支对比以了解当前项目的所有改动，review 这些改动并产出报告。我最关注这些内容：

- 代码逻辑错误或未考虑边界情况；
- 常见的不符合编程语言最佳实践的设计或写法；
- 过于复杂的可以被简化的类/接口/函数设计；
- 可能存在安全隐患的写法（例如 SQL 注入）；
- 重新实现了成熟库或项目其他模块已实现的功能（未复用）；
- 其他任何不符合项目规范、打破一致性，有问题的内容；

注意：创建 PR 前的 Review 并不直接替代之后的 AI 和人工 Review，这只是一种前置的自查。

让改动可验证，并总是验证

• 对于 AI 实现的代码，做好自动化测试和自测工作
• 杜绝提交未经测试的代码，去等待 Review 来“兜底”
  • 代码 Review 不可能找到所有问题，有些问题只有实际执行才能触发
  • 越后期发现的 bug，修复成本越高
• 鼓励编写自动化测试代码（单测、API 测试）等，做到 AI Agent 可自动验证，进入“验证<->修复”循环

其他

• 保持好奇心：对 AI 的代码，其中觉得新奇的库、模式或代码片段，打破砂锅问到底
• 拓展能力边界：打破思维惰性，去解决一些“如果没有 Agent”你绝不会去完成的任务
• 做正确的事：如果一开始的需求就错了，AI 会帮你在错误的道路上极速狂奔，所以“做正确的事”从未像现在这么重要

对初级工程师

经验不够丰富的初级工程师，对于编程语言和项目领域的理解尚处于早期，此时过度依赖 AI 或拖累学习效率，长远来看对能力发展有不良影响。因此，针对该类人群提供特定建议：

质量胜过效率

• AI 虽然是提效工具，但处于初级阶段时，应当更注重质量而非速度
• 快速地交付低质量的代码，实际上更低效（后续 review 反复调整、技术债务）
• 如果更慢的方式，能让自己学到更多东西，那么选更慢的（沟通好 deadline 的前提下）

尝试手动修复 Bug

• AI Agent 非常擅长全自动修复 Bug，但对于初级工程师…
• 不建议一股脑全丢给 Agent，由 Agent 完全无监督地“自动化”修复
• 用聊天模式，提出自己的思考和疑问，在分析 Bug 的过程中加深对项目的理解
• 这有助于更快、更深入地理解代码逻辑和架构

重复一次：多把 Agent 作为协作者来共同工作，而不是完全委派给 Agent。

自己先动脑，在 AI 给出的方案之外寻求

• 对任何任务，AI 给出的是“最有可能成立”的答案，但它不一定适合你
• 盲目遵循，丧失了拓展自身技术视野的可能性
• 先花一个固定的时间（如半小时）自己设计思路，之后询问对比 AI 给出的思路（先有解再“对答案”）
• 鼓励极限探索 AI 的能力边界

其他

• 让 AI 反问自己，通过问答来加强对项目和相关技术的理解
  • 类似让 AI 给你做一场关于项目的模拟“面试”
• 读官方文档：AI 知识有截止日期，存在幻觉问题， 文档仍然是深入掌握某项技术的首选（慢即是快）
• 补充软件设计和架构模式方面的短板，了解和学习设计模式、领域驱动设计（DDD）等
  • 现阶段 AI 并不擅长整体设计，更擅长在明确的框架下做具体的函数级实现
  • 良好的设计、健壮与灵活的架构，保证项目可持续迭代，离不开人来掌舵
  • 通过阅读书籍构建自己的知识体系
• 关注非功能性需求：AI 往往默认只关注“功能跑通”，忽视其他工程层面的问题：安全、可维护性、并发安全和扩展性等，有意识地去关注它们

结语

如有不同看法或补充条目，欢迎讨论。