一句话结论代码提示的第一原则：输入可复现——同样的输入要能得到同样的结果。
时间只够读一段的话，读这句：代码提示的结果是快照，口径才是底片。快照随时能重拍，底片搞错了全白拍。
先区分两件事：代码提示算出来的数，和你真正要用的数。两者之间差的那个口径，就是本篇要讲的东西。
- 关键数字单独核一遍，不依赖单一来源
- 结果出来先看数量级对不对，再看精确值
- 批量任务先拿三条试跑，确认再全量
为什么同样的输入结果不同
代码提示出错的剧本几乎每次一样：输入格式、参数口径、四舍五入位置。用熟之后，代码提示不再是按钮，它成了流程的一段。把代码提示当手艺更准确：手艺讲究的是稳定复现。
代码提示的可靠性挂在流程上，不挂在工具上。把核对点提前设计好，越用越依赖就少了一半。想明白这层，就不会把出错当成工具不行。
值得先讲清楚代码提示为什么不可靠，因为不可靠的原因高度集中。核对消耗的时间比计算大得多，所以有效的方法都在简化核对。
情形与做法：代码提示速查
| 情形 | 建议做法 | 核对点 |
|---|---|---|
| 流程稳定后 | 上批量，开模板 | 抽样核对 3 条 |
| 口径存疑 | 换算法交叉验 | 两种算法偏差范围 |
| 头两周 | 单条试跑，固定参数 | 结果与已知答案一致 |
| 输入格式变化 | 先改规范再跑 | 首条人工复核 |
| 报错出现 | 截图留档再处理 | 报错位置与原因 |
五分钟跑通代码提示
第一次用代码提示，把任务砍到最小：一条数据、一个参数、一次试跑。触发条件越具体越好：不是「要用的时候算」，而是「每到周一早上就算」。起步只需要两样东西：一份输入规范，一个核对点。
先写清楚「正确结果长什么样」，再开始操作。很多人卡在开头，是想一次做全，结果第一步都没跑通。先用一个已知答案的例子试：结果对得上，工具才是好的。第一次别调参数，只走通流程。
把代码提示嵌进固定流程
提前写好异常版本：输入缺失、格式不对、结果异常时怎么办。新流程挂在已有习惯后面，能免费继承稳定性。
让工具替你分担：模板固定在位，常见错误加一道校验。每加一个参数问一次是否必要，三个月后回看，一半可以删。复盘的意义不在追责，在于掐断「反正差不多」的侥幸。
代码提示最常见的六个错误
第二个坑是拿单次结果下结论：一次异常不可怕，可怕的是没核对就用了。把核对从「凭感觉」变成「按清单」，情绪就没机会插手。等代码提示稳定跑满两周，再动任何参数。
第三个坑是工具先行：装了一堆软件，就是没定输入规范。第一周能跑通，第三周必出幺蛾子。判断标准：你开始跳过核对了，风险就来了。
- 删掉一个多余参数，让流程更短
- 把代码提示的输入规范写成五行，贴在便签上
- 每周回看一次出错记录，只改一处
- 批量前先试三条，确认再全量
- 把默认参数抄下来，和自己的需求对一遍
- 把最常出错的那一步加一道校验
代码提示与其他工具的配合
这个阶段可以记录一个指标：耗时、出错率、返工次数。处理完一批要多久才能归档？要一整晚的话，该拆批了。能长期用的流程，恢复和回滚一定很快。
每月留十分钟复盘：什么有效、哪层漏水、下月只改一处。校验点守住了，提速才不会变成冒险。三周三个小改动，效率完全不同。
超出代码提示能力范围的事
出现这些信号时，代码提示的结果别信，先换方法。持续对不上官方口径，说明参数或算法理解有偏差。涉及个人敏感信息，优先本地离线处理，别随手上传。能长期用工具的人，都知道工具的边界在哪。
代码提示不是万能的，有些任务硬用它反而更慢。把代码提示当成最终结论是最危险的想法：它只做估算和核对。该走官方渠道的数字，别省那一趟。
常见问题
提示词写多长合适
结构比长度重要：任务、背景、格式、示例四件套齐了，几十个字就够用。
公司数据能传上去吗
先看公司制度。原则上客户信息、未公开财务、源代码都不进公开模型。
代码提示会不会取代这个岗位
它取代的是重复劳动部分。判断、担责、关系维护目前还得人来，方向是把省下的时间用在后者。
AI 说的能直接用吗
不能。把它当成一个反应快但会自信胡说的实习生：产出要核对，责任在你。
这篇的每个步骤，我们都实际跑过至少三遍才写下来。环境不同结果会有差异，核对点比结论重要。
最后一个提醒：不必等功能齐全。功能永远不齐，一个能立刻跑通的最小流程，比一个完美的工具箱有用得多。
对代码提示最诚实的总结：它可靠，但可靠是设计出来的，不是天生的。两周跑顺，三个月成流程。今天从一条数据开始，把规范写下来，剩下的交给重复。