先说背景
去年夏天，我还停留在“偶尔让 AI 补个函数”的阶段：正则写不出就搜一段，报错看不懂就贴给模型。一年过去，AI 已经嵌进我每天的开发流程，从补函数、写测试，到用 DeepSeek Harness 编排多个智能体并行干活。效率确实涨了：以前要花半天的查文档，现在半小时能收工；但学费也没少交。下面五个坑，都是我真金白银踩出来的，其中第三个让我返工了两天。
复盘这些坑，我发现它们有一个共同点：把 AI 当成“知道答案的人”，而不是“需要你验收的工具”。所以每一条我都按“具体场景 → 发生了什么 → 怎么避免”来写，最后附上我现在用的完整工作流。
坑 1：一本正经地胡说八道
具体场景
有一次我要解析一个不常见的日期格式，懒得查文档，直接让 AI 用“Python 标准库”实现。它很自信地回了一段代码，格式串对得上，注释也工整，我扫了一眼就提交了。
发生了什么
测试环境一切正常，一到生产就崩：那段“标准库”代码其实依赖了 dateutil 的宽松解析，而项目根本没装这个依赖。最讽刺的是，注释把行为描述得完全正确——错的是代码本身。AI 答错时往往语气特别笃定，这是它和人类专家最大的区别。
# 伪代码示意：AI 声称是标准库，实际依赖第三方库
from datetime import strptime
parsed = strptime("2026-08-01 24:00:00", "%Y-%m-%d %H:%M:%S")怎么避免
规则只有一条：关键代码必须实测。涉及 API 名、函数签名的地方，先在 REPL 里验证；要进生产的关键路径，补上单元测试再合入。AI 的自信程度与答案的可靠程度没有相关性，别因为它语气笃定就放松。
坑 2：上下文越长，越贵也越容易跑偏
具体场景
刚开始用 AI 改老项目时，我习惯把相关文件一股脑全贴进去，心想“信息给全一点，它才改得准”。改一个跨模块的状态同步，我塞了五个文件上万行。
发生了什么
两个问题一起爆。一是账单：每轮对话都要把上万行重新计费，几轮下来费用肉眼可见地涨。二是跑偏：上下文越长，模型越抓不住重点，开始在我没让它动的模块里“顺手优化”，最后不得不回滚重来。
怎么避免
原则是缩小上下文、一次只解决一个问题。大任务先拆小，先让 AI 读入口文件，再针对单个函数提问。上下文里只放“解决当前问题必需”的内容，无关文件、历史讨论、大段日志一律不进对话。省 token 是小事，不跑偏才是大事。
坑 3：把密钥和生产数据直接喂进去
具体场景
排查线上数据库连接问题时，图省事，我把整个本地配置文件复制粘贴给了云端模型——里面有连接串、API 密钥，还有一段脱敏不彻底的样例数据。
发生了什么
发出去几分钟后我反应过来，冷汗直冒：发出去的上下文，我无法保证它不被记录、不被用于训练。接下来的补救是轮换密钥、改连接串、翻日志确认没有敏感字段流出……前后折腾了两天才敢放心。这两天的返工，纯粹是我图省事换来的。
怎么避免
记住一句话：凡是要发出去的上下文，都当作“可能泄露”来对待。具体来说：
- 密钥、令牌、密码：一律换成占位符，如
sk-xxxx。 - 连接串、内网地址：脱敏成
host:port形式，不带账号密码。 - 真实用户数据：身份证、手机号、邮箱，全部替换成虚构样例。
- 公司内部代码：先确认保密约定，拿不准就不发。
用 DeepSeek Harness 编排多智能体时，我会在任务描述里显式声明“输入可能含敏感信息，先脱敏再处理”，让子智能体第一步就完成替换。
坑 4：省掉了 review
具体场景
AI 写得快，人审得慢，这个时间差很容易让人产生“省掉 review”的冲动。赶一个内部小工具上线时，AI 一次生成两千行代码，我扫一眼就提交了。
发生了什么
一周后，工具在某个边界输入下直接抛异常：空值没判断、异常没捕获、数组越界……全是“能跑但脆弱”的典型问题。更麻烦的是，循环里反复查询数据库的性能隐患，直到压测才暴露。回头再看，问题都写在明面上，只是我当时根本没看。
怎么避免
AI 写得快，你就得 review 得更细，这笔账省不掉。我的做法：先让 AI 自己审一遍自己，把潜在问题列成清单，人再复核；review 时重点看边界、异常路径、资源释放和性能热点；关键改动让 AI 生成测试用例，测试先跑，再人工看逻辑。
坑 5：把 AI 当替代品，而不是杠杆
具体场景
有一阵子我对 AI 的期望是“全自动”：需求写清楚，它直接产出整个功能，我只管验收。结果几次下来，要么结构完全不对，要么实现了一堆没人要的细节。
发生了什么
我发现自己在做一件很滑稽的事：为了把需求描述到“AI 能全自动完成”的程度，我写的说明比动手写代码还长。而且一旦期望它全自动，我就开始放弃判断——看到不合理的实现也懒得质疑，因为“反正不是我写的”。方向错了，AI 只是帮你把错误做得更快。
怎么避免
把 AI 定位成杠杆而不是替代品：它负责广——查资料、起骨架、生成样板代码；你负责准——判断、取舍、把关。凡是产品方向、架构决策、安全底线，方向感永远得是自己的。一句话：AI 负责“怎么做”，人负责“做什么、为什么做、做到什么程度算好”。
我现在的完整工作流
把五条教训沉淀成固定动作后，我的返工率明显降了下来。现在分五步：
第 1 步：拆任务
把需求拆成可以独立验证的小任务，每个任务只问一个问题。拆得越细，AI 越不容易跑偏，也越方便并行。这一步永远是人来做，AI 可以帮你列拆法，判断权在你。
第 2 步：并行调研与起草
互不依赖的任务分给多个会话并行处理：一个查文档，一个起骨架，一个写测试。用 DeepSeek Harness 编排时，我给每个子任务写清输入、输出、约束和验收标准，并声明脱敏要求。
第 3 步：逐段审校
结果回来先看结构再看细节：接口对不对、边界有没有、注释和代码是否一致。发现问题就带着上下文回去迭代，让 AI 学会你的标准，比修一次代码更有价值。
第 4 步：实测
进生产之前，关键路径必须实测：单测、集成测试、真实环境冒烟。“AI 说没问题”不等于“没问题”，这一步没有捷径。
第 5 步：脱敏提交
提交前做一次敏感信息扫描：密钥、内网地址、真实数据。可以脚本化，也可以让 AI 做反向检查——记得先脱敏再让它看。
如何写好提示词
同样的模型，提示词清不清楚，产出能差一个量级。几个实用技巧：
给足上下文，但只给相关的
相关代码、报错、预期行为给足；无关讨论、大段日志不给。上下文的质量比数量重要得多。
明确输出格式和约束
说清楚要什么形态：语言、框架、函数签名、返回格式、不要做什么。约束写清楚，能省掉大量返工。
让 AI 先复述需求再动手
复杂任务先让 AI 用一两句话复述需求，确认理解一致再开始，提前暴露“你想要的”和“它理解的”之间的偏差。
用“差评”式反馈迭代
不满意时别说“不对”，要说哪里不对、期望是什么。反馈越具体，下一版越接近目标。
一个可复用的提示词模板：
任务：为下面的函数补全单元测试。
输入（函数签名与行为说明）：请在这里粘贴
输出要求：
- 使用 pytest，覆盖正常、边界、异常三种情况；
- 每个用例一行注释说明意图；
- 不要修改被测函数本身。
约束：依赖的 mock 对象已在 tests/conftest.py 中定义。把模板存成常用片段，改改“任务”和“输入”就能复用，比每次从零写稳定得多。
什么时候别用 AI
AI 不是万能的，这几类场景我基本不用它：
- 你没能力 review 的领域：安全、密码学、底层协议。AI 的错你发现不了，等于把未知风险引进来。
- 安全敏感的内容：涉密代码、生产密钥、真实用户数据，别进云端模型。
- 需要稳定复现的结论：AI 是概率模型，同一问题两次回答可能不同，可复现的场合靠文档和规范。
- 责任必须在人身上的事：生产事故定责、对外承诺、法律文书。AI 可以起草，签字担责的只能是人。
- 你想借它偷懒的时候：当你用 AI 是为了不学习、不思考、不看文档时，停一下——那正是你该自己动手的时候。
判断标准就一条：如果它错了，你能不能发现？能，AI 是杠杆；不能，AI 是风险。
常见问题
AI 用多了，我会不会变菜？
取决于怎么用。把它当“答案生成器”，确实会退化；当“结对伙伴”，先自己想方案再让 AI 验证补全，反而学得更快。关键是 AI 给出答案后，至少读一遍、理解一遍。
免费模型和本地模型够用吗？
够用。补函数、写测试、改 bug 这些日常任务，免费模型完全胜任；涉及敏感数据时，本地模型更稳妥。建议按任务敏感度分层选模型。
已经泄露了密钥怎么办？
别慌，按顺序处理：立即轮换密钥、撤销令牌；排查日志和版本库历史，确认有没有落入持久化存储；然后把脱敏改成提交前的强制步骤。处理泄露不难，难的是下次别犯。
编程新人适合用 AI 学习吗？
适合，但要有纪律：先自己写，再让 AI 改；看不懂的每一行都要问明白；让 AI 解释“为什么这么写”，而不是直接抄。把 AI 当成随时在线的老师，而不是代写作业的枪手。
行动小结
如果这篇文章你只带走五件事：
- 关键代码必须实测，别信语气，信结果。
- 一次只问一个问题，上下文宁小勿大。
- 发出去的每一条上下文，都当作可能泄露。
- AI 写得快，你就 review 得更细。
- AI 是杠杆，不是替代品，方向感永远是自己的。
工具会迭代，模型会升级，但“人负责判断、AI 负责执行”的分工原则短期内不会变。愿你少踩几个坑——最好一个都别踩。