给 AI 工具留一份可复查的工作记录

文章目录

记录要能回答“为什么能用”

这是一套可自行调整的参考方法，用于写作、代码修改和资料整理，并非某个产品的固定流程。聊天记录可能很长，却不容易说明最后采用了什么结果。单独留一份简短工作记录，可以让下一次接手时迅速找到目标、依据和仍未解决的问题。

开始前先写完成标准。例如“修正移动端导航，三个入口均能打开，窄屏没有横向滚动”，比“帮我优化网站”更容易验收。再列出允许修改的范围和必须保留的内容，防止任务在对话中逐渐扩大。

日期与任务：
目标与完成标准：
输入材料及其来源：
工具与可见版本信息：
采纳的结果与文件位置：
人工核对与实际测试：
未确认事项与下一步：

输入材料记录到能重新找到即可：文件路径、文档标题、链接和访问日期通常比整段复制更实用。工具名称与版本只填界面确实显示的信息，不清楚就写“未显示”。需要复现的任务，再补充关键指令和影响结果的设置，避免把记忆里的配置当成事实。

AI 给出的解释可以先记为“建议”或“待核对”。采纳前打开原始资料，确认链接确实支持这句话，并检查适用版本、前提条件和例外。数值、日期、命令参数尤其适合逐项核验。来源无法找到时，就保留不确定状态，或删去这条结论。

代码任务还应查看实际文件变化。在已使用 Git 的项目里，可以用下面几条只读检查作为记录依据：

git status --short
git diff
git diff --cached

status 可帮助识别已修改、已暂存和未跟踪文件，短格式的两列需要结合文档理解，见 Git 状态命令说明。普通 diff 查看尚未暂存的变化，--cached 查看已暂存的变化，详见 Git 差异命令说明。新建的未跟踪文件还要打开检查，不能只读差异输出就认为已经覆盖全部改动。

“看起来正常”很难复查。更有用的写法是“已在窄屏打开首页，三个导航链接均能跳转；尚未测试触屏设备”。写下执行过的检查、观察到的结果和没覆盖的范围，让结论与证据相称。失败也值得保留一句原因，方便下次避开相同前提。

结束时把最终文件、验证结果和剩余事项放在一起。记录中不保存密码、访问令牌、私钥或客户原始数据；引用报错时先做必要脱敏。以后复用旧记录，应重新检查依赖和来源是否仍然适用，别把一次成功当成永久保证。