AI编程助手从代笔到陪练：提示词、测试与代码评审实战

1. 先想清楚：AI 助手到底是"代笔"还是"陪练"

我第一次把 ChatGPT 这类对话式 AI 助手拖进日常编码流程，动机特别朴素——不想写重复的样板代码。半年后回头看，真正让我效率翻倍的，反而不是它帮我敲了多少行代码，而是它在我含糊其辞的时候把我问住了。这两种体验差别极大，前者是"代笔"，后者是"陪练"，而大部分人对 AI 编程助手的失望，都源于用代笔的期待去要求一个陪练。

这个标题里的"智能伙伴"和"思维导师"，其实是两个层级。智能伙伴解决的是手速问题：脚手架、正则、序列化、边界判断、命名建议、日志格式、单元测试骨架，这些活儿它的确又快又稳。思维导师解决的是判断问题：方案有几种、每种代价是什么、我漏了哪个异常分支、这个抽象是不是过度设计。前者省时间，后者省返工。而返工往往比打字贵得多，所以我现在的用法重心明显偏向后一层。

这篇文章适合三类人看：刚入行、还没建立起自己判断体系的新人，可以参考我下面的提示词结构和提问顺序；工作三五年、被重复劳动磨得没脾气的中间层，可以看看怎么把琐碎活外包出去；带人的同学，可以看看怎么用 AI 辅助做代码评审和方案复盘。全文讲的都是方法论和实操细节，不讲玄学，也不吹神效。

1.1 三个角色定位，决定了你该怎么开口

我把 AI 助手的使用方式粗略分成三种角色，每种角色的对话方式、验收标准、风险点都不一样。搞混了角色，就会出现"我让它写个模块，它写了一堆看起来对但跑不通的东西"的经典翻车。

打字机模式最容易上手，也最容易让人产生"AI 真强"的错觉。你把一个写得极其详细的函数需求贴进去，它给你的代码八成能跑。但问题在于：能把需求写得那么详细的人，本身就不太需要它写这段代码了。真正有价值的场景是中间那段——你有模糊的想法，需要有人帮你把边界逼出来。

陪练模式的关键动作是"让它先问"。我现在开一个新话题，第一句几乎固定是："先别写代码，你反问我三个问题，确认需求边界。"它问出来的三问，经常能戳到我漏掉的东西，比如"并发情况下这个方法会被重入吗""空列表是返回空还是抛异常""这个字段是必填还是可以延迟加载"。这三个问题本身就值回票价了。

审阅者模式是最被低估的。写完一段逻辑复杂的代码，把它和上下文一起贴过去，要求"只找问题，不要重写"，通常能捞出两三类我自己视而不见的疏漏——空值穿透、异常吞掉、循环里做了数据库查询。它不会理解你的业务语义，但机械性的疏漏它比人眼稳定。

1.2 我在真实项目里踩过的两种极端

第一种极端是全盘信任。某次做数据导入，我把一段解析逻辑丢给它，代码看着干净利落，跑小样本完全正常。上线后遇到一个十万行的脏数据文件，内存直接飙上去——它在循环里每次都新建了一个列表做浅拷贝。这种错误人也会犯，但人犯的时候往往有"这段代码我写的，我知道哪里危险"的警觉，而 AI 给的代码你天然缺乏这种肌肉记忆。

第二种极端是全盘否定。有一阵子我看到 AI 给的代码就下意识觉得"肯定有坑"，宁可自己从头写。结果是我花了两小时手写一个树形结构的扁平化，它三十秒给了个递归加缓存版本，我对着看了五分钟发现确实比我的干净。偏见本身也是成本，而且这个成本是隐性的，你不会意识到自己慢了多少。

现在我给自己定的规矩是：代码可以信，结论不可信；结构可以信，边界不可信。它给的架构建议、命名建议、拆分方式，通常有参考价值；它给的具体 API 调用、异常处理、并发行为，一律当草稿对待，必须自己跑一遍。这个区分标准简单粗暴但极其有效。

1.3 什么时候该果断放下它

有三类场景我会直接关掉对话框自己干，因为用 AI 反而更慢。

第一类是高度依赖内部上下文的改动。比如某段代码为什么写成这个古怪样子——因为三个月前有个特殊的兼容需求。这种"历史包袱"你没法学给 AI 讲清楚，讲了它也只能按你说的做，那还不如自己动手。

第二类是细粒度调优。性能瓶颈定位到某一行之后，剩下的工作往往是"把这行换成另一种写法，然后压测对比"，这种活儿需要极短反馈循环，人和工具来回切换的开销大于收益。

第三类是需要承担责任的判断。选型、架构分层、对外接口设计，这些最终签字的是你。AI 可以给你列清单，但不该替你做决定，尤其不该替你做"我们放弃这个方案因为代价太高"这种决定。

2. 提示词不是咒语：把需求拆成机器能接住的形状

很多人抱怨"AI 写的代码不能用"，其实问题往往出在输入。你给它一句"帮我写个用户登录"，它能做的只能是猜——猜你的技术栈、猜你的密码存储方式、猜你要不要限流、猜失败几次锁定。猜错的概率远大于猜对，于是你觉得它不行。这不是它笨，是你给的信息熵太高。

提示词的本质不是"咒语"，是需求文档的极简版。你在公司写需求评审的时候会写什么，就应该在对话里写什么，只是可以更口语化、更短。

2.1 三要素：上下文、约束、验收标准

我总结下来，任何一个靠谱的代码请求至少要包含三样东西，缺一样翻车率就明显上升。

上下文回答"这是什么环境"。语言版本、框架、现有代码风格、相关的数据结构、这段代码在整体流程里的位置。我习惯一次性把关键信息压缩成几行贴上去，比如："Python 3.11，无第三方依赖，项目里已有Result数据类和fetch_user函数，风格偏函数式，不用类。"这几行字能挡掉大半的"它给我用了个我没装的库"。

约束回答"不能做什么"。这是最容易被忽略、但收益最高的一环。不许用某个库、不许改函数签名、不许引入全局状态、复杂度不能超过多少、必须保持向后兼容。约束写得越具体，它的输出越收敛。

验收标准回答"怎么算做好了"。这是区分业余和专业的分水岭。不要说"写个排序函数"，要说"输入是可能含重复元素的整数列表，返回去重后升序列表；输入为空返回空列表；不修改入参；时间复杂度尽量控制在线性对数级别"。有了验收标准，它自己就会去覆盖边界。

提示：如果一次对话里你发现自己在反复纠正同一个问题，八成是约束没写清楚，而不是它理解力不行。停下来说清楚约束，比来回改五轮省时间。

2.2 逐层收敛，别一次把整个系统塞进去

新手最常见的操作是：把三千行项目代码粘贴进去，说"帮我找 bug"。结果要么它抓了三个空格缩进问题，要么它开始编造你没写的函数。这不是能力问题，是信息过载。

我的做法是分层递进，每一层只解决一个粒度的问题：

1. 架构层：只贴目录结构、模块职责说明，问"这个分层有什么明显问题"。
2. 模块层：贴单个文件的完整代码，问"这个模块的职责是否单一，有没有隐藏耦合"。
3. 函数层：贴单个函数和它的调用方，问"边界条件是否覆盖完整"。
4. 行级：贴几行有疑问的代码，问"这里的并发安全吗"。

每层之间的信息量控制在它能够"完全读懂"的范围内。我的经验阈值是：单次粘贴代码控制在 200 行以内，超过这个量，它开始出现"记得前面忘了后面"的情况。这个数字跟模型上下文长度无关，跟注意力分配有关——上下文再长，能真正用上的有效信息也是有限的。

2.3 一份我常用的提示词骨架

下面这段是我从无数次调整后沉淀下来的模板，直接抄就能用，按需替换方括号里的内容。

【角色】你是一位有十年经验的[Python/Java/前端]工程师，擅长在既有代码库中做最小改动。 【上下文】 - 语言与版本：[Python 3.11] - 依赖限制：[只用标准库，不允许新增第三方包] - 现有相关代码：

[贴 50 行以内的相关代码]

- 数据规模：[单次处理量约 2 万条，日均调用 500 次] 【任务】 [用一两句话描述要做的事，不要写实现思路] 【约束】 - 不修改现有函数签名与返回值结构 - 不引入全局可变状态 - 异常情况统一返回 Result.fail，不抛未捕获异常 - 单次执行内存占用不超过 [XX MB] 【验收标准】 1. [输入 A，期望输出 B] 2. [空输入的行为] 3. [异常输入的兜底行为] 【输出格式】 先给出你的思路和 2 个以上备选方案及各自代价，等我确认后再写代码。

最后那句"先给思路，等我确认"是整段模板的灵魂。它把一次性的"生成-返工"循环，变成了"对齐-生成"循环。多花一轮对话，少改三轮代码，这笔账很划算。

2.4 五个高频反模式，我几乎每天都见

反模式一：需求里带答案。"用递归帮我实现这个树遍历"——你已经在实现层面做了决策，它只能照着写，没法告诉你这棵树深度可能上千、递归会爆栈。

反模式二：一次问五个问题。一段消息里塞了"优化性能、加日志、改命名、补测试、修 bug"，它的注意力会被摊薄，通常只把最显眼的两三件做了。

反模式三：不给失败案例。只说"这个函数有问题"，不说"A 输入正常、B 输入返回错"。它只能靠猜，猜错你就觉得它笨。

反模式四：用形容词代替量化指标。"优化一下性能"和"把单次耗时从 1.8 秒压到 100 毫秒以内"，得到的方案质量完全不在一个层次。

反模式五：不追问。它给了一个方案，你看一眼觉得"大概行"，就直接用了。正确姿势是追问一句"这个方案在什么情况下会失效"。这一问经常能让它自己把坑挖出来，比你自己想半天快得多。

3. 从需求到可运行代码：一条完整的实操链路

光讲原则容易空，我把最近做的一个模拟项目完整走一遍。场景是：内部工具需要一个日志解析模块，把混合格式的文本日志解析成结构化记录，然后按时间窗口聚合统计。数据量不大，两万行左右，但格式很脏，有几种历史遗留的变体。

3.1 第一步永远是澄清需求边界

我没有直接说"帮我写日志解析"。我的第一句话是："我要做一个日志解析模块，输入是文本行列表，输出是结构化记录列表。在动手之前，请你反问我五个问题，覆盖你没把握的地方。"

它问的五个问题里，有三个是我确实没想清楚的：格式不认识的行怎么办（跳过还是报错）、时间戳没有时区的怎么处理、字段缺失是给默认值还是标 null。这三个问题逼我回去翻了一遍历史日志样本，发现大约 3% 的行是残缺的。于是我在需求里补了一条："残缺行统一收集到 rejected 列表，不中断整体流程，最后统计拒绝率。"这一条如果没想清楚，后面整个模块的异常处理都得推倒重来。

这就是我说的"思维导师"价值——它不一定比你懂业务，但它比你更愿意把模糊地带摊开。人写代码容易急着开工，AI 不会急。

3.2 接口先定，实现后填

需求边界清楚了，第二步不是写实现，是定接口。我要求它只输出函数签名、数据类定义和文档字符串，不写任何函数体。这一步的产出大概是这样的：

from dataclasses import dataclass, field from datetime import datetime from typing import Iterable @dataclass(frozen=True) class LogRecord: ts: datetime level: str source: str message: str raw: str @dataclass class ParseReport: records: list[LogRecord] = field(default_factory=list) rejected: list[tuple[int, str]] = field(default_factory=list) @property def reject_rate(self) -> float: total = len(self.records) + len(self.rejected) return len(self.rejected) / total if total else 0.0 def parse_lines(lines: Iterable[str]) -> ParseReport: """解析混合格式日志行，无法识别的行进入 rejected，不抛异常。""" ...

接口定完，我先自己看了一遍：rejected存的是(行号, 原始内容)，这个设计比存异常对象好，因为后面要做人工回捞。frozen=True是我加的，理由是这个记录一旦产出就不该被下游改动。接口阶段花十分钟，能省掉后面两小时的返工，因为所有实现细节都被约束在一个稳定的外壳里了。

3.3 让它写测试，比让它写代码更值钱

这是我整个流程里最推荐的改动：先让它写测试用例，你确认测试，再让它写实现。

我给出的指令是："基于上面的接口，写 12 个 pytest 用例，覆盖：正常行、字段缺失行、时间戳格式异常行、空输入、只有空白的行、超长行（超过 10000 字符）、中文与英文混排、混入不可打印字符、以及三种历史格式变体。"

它给的 12 个用例里，有 2 个我自己没想到：一个是"同一行里出现两个时间戳该取哪个"，一个是"行尾带\r\n和只有\n的差异"。前者是真实存在的情况——应用层拼接日志时会重复打时间戳；后者在跨平台文件里极其常见，Windows 导出的日志带\r，正则写不好就会把\r吃进 message 字段。

有了这 12 个用例，后面写实现就是纯体力活，而且有了明确的完成信号——跑通全部用例就算完事。这比"看着差不多就行"强太多。

实操心得：让 AI 写测试的时候，明确要求"每个用例只用一行 assert，不要写辅助函数"。用例越扁平，出问题时定位越快。它天生喜欢抽象，你不约束它，它能给你套三层 fixture。

3.4 重构阶段用对比法，不要用"优化一下"

第一版实现跑通测试后，我做了一轮重构。常见的错误指令是"优化这段代码"，太模糊。我用的是对比法："下面给出两版实现，请从可读性、异常安全性、最坏情况性能三个维度对比，指出各自会在什么输入下失效。"

我拿到的对比反馈里，有一条很关键：第一版用了一长串if/elif判断格式，随着格式变体增加会持续膨胀，而且判断顺序会影响结果——如果一个宽松的正则排在前面，会把本该匹配严格格式的行先吃掉。第二版改成了按"格式特征"做分派，每种格式自带校验函数，匹配失败自动落到下一个。这个改动不大，但把扩展性从"改函数体"变成了"加一个注册项"。

这里有个细节值得说：我要求它给出"会在什么输入下失效"，它指出了第二版的一个隐患——如果一行同时满足两种格式的特征，会走第一个注册的，可能解析出错。这个隐患在我的实际数据里确实出现过一次，占比约 0.2%。虽然是极小概率，但至少我知道了这个风险的存在，而不是稀里糊涂上线。

3.5 一个性能数字的推导过程

聚合统计那部分，最初版本是双循环：对每条记录，遍历所有时间窗口判断归属。数据量两万条、窗口两千个，理论比较次数是四千万次。实测耗时约 1.8 秒，慢得离谱。

我把它贴给 AI 时，没有说"太慢了帮我优化"，而是给了数据："两万条记录，两千个时间窗口，当前是双层循环，实测 1.8 秒。目标压到 100 毫秒以内。数据特点：记录已按时间升序，窗口大小固定。"

它给的方案是把窗口起点做成哈希表，每条记录通过时间戳整除窗口长度直接定位到窗口索引，复杂度从 O(n·m) 降到 O(n)。这个思路本身不新鲜，但它在回复里补了一句我没考虑到的："因为记录已排序，可以用一个游标单调推进，连哈希表都省了。"

改完之后实测 40 毫秒左右。这个例子的重点不在优化技巧，而在于你给的数据越具体，它的方案越具体。"太慢了"只能换来"用缓存吧"这类空话，给出规模、目标、数据特征，才能换来针对性的方案。

4. 把它当"思维导师"：用提问换取判断力

前面讲的多是"让它干活"，这一节讲"让它陪你思考"。这部分没法量化收益，但长期看价值更大，因为它训练的是你自己的判断力。

4.1 反问式用法：让它先问你三个问题

这个技巧我逢人就推荐。任何稍微复杂一点的任务，第一句都加"先别动手，反问我三个问题"。它问出来的问题，往往精准命中你思维里的空白区。

举个具体例子。我在设计一个缓存淘汰策略时，本来的想法很简单：按访问时间做 LRU。让它反问，它问了三个："缓存的 value 计算成本高吗""访问分布是长尾还是均匀""内存上限是硬的还是软的"。这三个问题直接改变了方案——因为 value 计算成本低，缓存的意义不大；访问分布是长尾，LRU 会把大量一次性数据挤进缓存又很快淘汰。最后我改成了按访问频次加权的方案，缓存命中率从 40% 出头提到了 70% 左右。

注意，它没有告诉我答案，它只是让我自己发现了问题。这就是"导师"和"工具"的区别。

4.2 逼它列代价，而不是列好处

AI 有个天然倾向：你问"A 方案好不好"，它会告诉你 A 方案好在哪。这是训练数据带来的讨好倾向，不是它真的认为 A 好。破解办法是换个问法：不问"好不好"，问"什么时候不该用"。

我常用的句式有三句，效果很稳定：

• "这个方案在什么场景下会明显变差？给我三个具体例子。"
• "如果团队只有两个人维护，这个设计还成立吗？"
• "把 A 和 B 放一起，列出各自的隐性成本，不要列优点。"

最后一句特别好用。让它列"隐性成本"，它会说出一些很实在的东西，比如"引入了额外的抽象层，新人理解成本上升""需要额外的监控指标，否则出问题无法定位""调试链路变长，本地复现困难"。这些东西在技术选型的文档里通常不会写，但它们才是真正决定项目能不能维护下去的因素。

4.3 啃陌生技术栈的正确姿势

我最近需要在一个完全没接触过的生态里写一个小工具。传统的学习路径是看官方文档、找示例、跑 demo，大概要一两天才能上手。我的做法是把节奏压缩了一下：

第一步，让它"用一段话讲清楚这个生态的核心抽象是什么，和[我熟悉的某个东西]最像的地方在哪，最不像的地方在哪"。类比是理解的捷径，而它很擅长找类比。

第二步，让它"给一个 30 行以内、能直接跑的最小可运行示例，不要任何工程化包装"。这一步的目的是建立"我改一行会发生什么"的直觉，不是学最佳实践。

第三步，也是最关键的一步："列出新手在这个生态里最容易犯的五个错误，每个错误给一个错误写法和正确写法。"这一步价值极高，因为文档通常只讲正确用法，不讲常见错误。我照着这五条检查自己的代码，避开了三个坑。

第四步才开始正经写业务代码，边写边问。

这套流程下来，我大概半天就能写出能用的东西。速度的秘诀不在于学得快，而在于跳过了大量暂时用不上的知识，等真正需要时再回头补。

4.4 用评审视角做自我校验

写完一个模块，我有个固定动作：把代码贴过去，配一句话——"假设你是要接手这段代码的人，请指出三处你会在 code review 里打回的地方，按严重程度排序。"

这个指令的精妙之处在于"假设你要接手"。如果只说"找 bug"，它会盯着语法和边界；加上"接手"这个前提，它的关注点会转向可维护性——命名是否达意、副作用是否隐蔽、错误信息是否有用、有没有留下"看不懂为什么这么写"的地方。

我拿到的反馈里，出现频率最高的三类是：函数做了太多事、异常被静默吞掉、魔法数字没有解释。这三类恰好也是人类评审最常提的。区别在于，人评审要等同事有空，AI 评审随时可以。

5. 高频翻车现场与排查手册

用了这么久，翻车类型其实高度集中。我把它们整理成速查表，遇到问题先对号入座，比盲目重试快得多。

5.1 幻觉接口：看起来最像真的，错得最离谱

这是最危险的一类。它会给你一个参数名、方法名、配置项，格式完全正确，命名风格完全符合那个库的习惯，但这个东西根本不存在。危险在于它太像真的，你不去查文档直接用了，报错信息还特别绕，容易让人以为是环境问题。

我的防线有三层。第一层是凡是涉及外部库的调用，一律要求它给出对应的官方文档链接或版本号，它给不出来或者给得含糊，就标记为待验证。第二层是先跑一个最小验证，五行代码验证这个 API 存在且行为符合预期，再往业务代码里写。第三层是优先让它用标准库，标准库的 API 相对稳定，幻觉率低得多。

有个细节值得注意：同一个 API，它在不同轮对话里可能给你不同的签名。这不是它"记错了"，是不同版本的训练数据混在一起。所以明确告诉它你的版本号，能大幅降低这类问题。

5.2 边界条件：它总在"正常路径"上表现优异

给它一个函数需求，它写出来的主逻辑通常很漂亮，边界处理则经常敷衍。典型表现：空集合没判断、除零没防、负数索引没考虑、字符串截断没处理多字节字符。

我的对策很直接：在验收标准里把边界逐条列出来，而不是指望它自己想到。我常用的边界清单是这几类：空、单个、极多、超长、含空白、含特殊字符、并发访问、重复调用、依赖失败。每类至少要求一个用例。这份清单是我踩坑踩出来的，比任何最佳实践文档都好使。

5.3 上下文漂移：聊到第十轮，它开始"记错"前面的约定

长对话必然出现这个问题。你在第一轮说了"不要用类"，到第十轮它又开始写 class。这不是它故意违背，是早期信息在长上下文里的权重衰减了。

解法是把关键约束固定在每一轮的开头。我习惯在每轮消息前加一行简短的"约定回顾"，比如："约定：函数式风格、不新增依赖、返回值统一用 Result、异常不外抛。"这一行不到三十个字，但能显著提升一致性。

另一个办法是主动重置。当话题从模块 A 转到模块 B，我会新开一个对话，把必要的上下文重新贴一遍，而不是在旧对话里继续。旧对话里那些已经完成的讨论，对新任务来说是噪音。

5.4 一张排查速查表

注意：最后一行是我最想强调的。让 AI 写测试有个隐患——它写的测试和它写的实现出自同一个"理解"，如果理解错了，测试也会跟着错，你还能看到一片绿。所以关键模块一定要自己补一两条"刁钻"用例，专挑它可能没想到的路径。这两条用例才是真正的守门员。

6. 把 AI 助手接进日常研发流

单次对话的技巧容易学，难的是把它变成稳定的日常习惯。我现在的流程里，AI 助手出现在四个固定节点，每个节点有明确边界。

6.1 开工前：需求澄清与方案对比

这个节点的产出是一段话的方案说明，不是代码。内容包括：要做的事、边界在哪、有哪两三个备选方案、各自主张什么、我选哪个以及为什么。这段说明我会直接贴进任务描述里，后面无论是自己写还是让别人接手，都不用重新想一遍。

这一步的价值在时间维度上特别明显。写这段说明大概花十分钟，但它能挡掉后面半天的方向性返工。方案错了，代码写得再漂亮也是白写。

6.2 编码中：碎片化求助，不打断心流

编码阶段我用得很克制，只在三种情况开口：想不起某个标准库的用法、需要一段样板代码、卡在一个没头绪的报错上。这三种情况共同特点是目标明确、边界清晰，问完就能继续干活，不会打断思路。

反面例子是"帮我设计这个模块"。这种问题一旦开口，很容易陷入十几轮的来回讨论，写着写着思路就散了。设计类的问题我会挪到 6.1 那个节点，专门留时间做，不在编码时穿插。

6.3 提交前：一道机械疏漏的闸门

这是我最坚持的一个习惯。git commit之前，把本次改动的 diff 贴过去，配一句："只列出你会打回的问题，不要重写代码，不要夸奖。"

它给出的问题清单里，最常见的三类：调试用的打印语句没删、异常分支里只写了pass、临时变量名没改。这三类问题人类评审也会提，但它们属于"机械性疏漏"，用人工时间去抓实在浪费。让 AI 当这道闸门，人评审就可以专注在逻辑和设计上。

这一步有个小技巧：要求它按严重程度排序，并且明确说"如果没有严重问题就直说没有"。不这么要求，它会为了显得有用而硬凑几条，反而增加噪音。

6.4 复盘时：把踩过的坑沉淀成规则

每隔一段时间，我会把这段时间遇到的问题汇总起来，让它帮我归类："下面是我这段时间遇到的十个问题，帮我归类，并提炼成五条可以写进团队规范的短句。"

这一步的产出是给自己的，不是给 AI 的。比如我从这类复盘里提炼出的几条：外部依赖调用必须先做最小验证；关键模块的测试必须自己补异常用例；单次贴给工具的代码不超过 200 行；约束条件写在每轮对话开头。这些规则积累下来，比任何"AI 使用指南"都贴合自己的实际。

6.5 权限与数据的边界意识

这一段单独拎出来说，因为它的代价可能最大。我的原则很明确：内部业务逻辑、真实数据结构、密钥配置、用户信息，一律脱敏后再上对话。

脱敏不是简单删几行，而是要做"结构保留、内容替换"。表名改成t_user这种泛化名字，字段值换成明显的假数据，业务规则用"某个条件触发某个动作"这种抽象描述代替。这样它依然能理解逻辑结构，给出有效的建议。

我一般会花两三分钟做这个准备工作。这两三分钟换来的是放心，也是对自己项目的负责。图省事直接粘贴，风险和你省下的时间完全不成比例。

6.6 长期使用后我形成的几条习惯

最后分享几条坚持了半年以上的习惯，都是小事，但叠在一起效果很明显。

第一，永远保留一个"为什么"的记录。每次采纳 AI 的建议，我会在提交信息里补一句为什么这么改。半年后回头看，这些记录比代码本身有价值——它记录的是判断过程，而不是结果。

第二，不追求一次问对。早期我总想让提示词完美，一次问出最优解。后来发现，与其打磨提示词，不如快速问三次、对比三个答案。三次粗糙的提问，胜过一次精心设计的提问，因为对比本身就是信息。

第三，每周留半天不用它。这个习惯有点反直觉，但很有必要。完全依赖工具会导致自己的能力退化——尤其是"从零开始想一个问题"的能力。留出不用它的时间，是给自己做体检，看看哪些能力还在、哪些已经生锈了。

第四，把它当同事而不是神谕。同事给你的建议你会判断、会验证、会追问，对 AI 也应该如此。我见过不少人，AI 说了一句话就当成定论，转头去跟别人争论。这种信任度给得太轻易了。

我个人的实际体会是，这类工具真正的价值不在"帮你写代码"，而在"帮你把想清楚的成本降下来"。写代码只是最后一步，前面那些澄清需求、对比方案、检查边界的活儿，才是决定一个模块能不能活过三个月的东西。工具替不了你判断，但它能让你有更多余裕去做判断——这个余裕，才是效率提升真正发生的地方。