构建记录怎么写？一份能直接套用的四段式模板

构建记录可以先写成四段：问题、工具、结果、下一步。它的用途是让下一次接手的人知道做过什么、凭什么判断、还有哪些地方没有确认。

下面给出可复制的模板和一份虚构的填写示例。四段是组织建议，没有固定字数要求；复杂的项目可以另附操作步骤、配置和测试证据。

一份可以复制的模板

问题：
谁在什么场景遇到什么问题？这次做到哪里，哪些功能不在范围内？

工具与环境：
工具/模型及实际版本：
运行环境和依赖：
关键输入文件或样本版本：
选择这套方案的原因：

结果：
实际修改或产出：
验证日期、环境和身份：
操作 → 预期结果 → 实际结果：
通过/失败/未测试的项目：
证据位置（截图、日志、代码或演示）：

下一步：
需要解决的一个问题：
已尝试的方法及结果：
需要补充的条件或协助：

不知道实际版本时，写“当时未记录，待确认”。查当前官方文档有助于补查能力范围，但不能证明你过去运行的就是那个版本。

填写示例：列表页标签筛选

以下是虚构的格式示例，没有对应已完成的测试或项目。

问题：给一个本地作品列表增加标签筛选，刷新后保留选择。本次不增加后台编辑、搜索和用户权限。

工具与环境：浏览器本地页面、固定的示例数据文件。编程工具版本在实际记录时填写；此处没有运行工具，所以不填一个虚构版本。选择 URL 查询参数是为了让筛选条件能够被复制和直接打开。

结果：示例作者应分别检查点击标签、清除条件、刷新、直接打开筛选链接和空结果。可以记录为“点击标签显示对应项目，通过；刷新保留选择，通过；直接打开链接，尚未测试”，并附实际截图或日志。这里描述的是填写方式，不能作为通过证据。

下一步：补测直接打开链接与浏览器前进后退。若结果不一致，先确认 URL 读取和点击事件是否使用同一套筛选逻辑。

代码、提示词和证据分别放什么

代码选择能够解释关键实现的片段，并说明文件位置、依赖和调用方式。整仓库链接可作为补充，但不要把读者需要了解的关键条件全藏在仓库里。公开前移除密钥、账号凭据和不应公开的数据。

提示词保留与这次结果有关的原文、输入条件和改动原因。最终版能说明现在怎么用，失败版本与差异则能帮助解释为什么这样修改。没有比较过时，不要写某一句话“使效果提高了多少”。

截图用于说明当时看见的状态；日志用于定位执行过程；可运行演示用于让读者自行操作。这几类证据各有用途，不能用一张成品图代替全部验证。

验证状态必须与实际证据一致

• 未实际按步骤运行的方案，保留“未验证”。
• 作者运行过，只能说明所列环境、样本和步骤的结果，不代表所有场景都可靠。
• 其他人复现过，应写清复现条件及差异，再按站点实际规则标注，不能自行推定“社区已验证”。

工具或接口升级后，要说明原证据对应哪个版本，以及哪些部分需要重验。项目是否完成与结论是否经过验证是两件事，应分别记录。

发布前检查

读者能否根据记录找到输入、环境和执行步骤？每一个“可用”结论是否都有对应操作？失败和未测试项是否明确？下一步是否具体到能够执行？

如果还缺一项，直接写明缺口。记录的价值来自信息准确，不来自把所有格子都填成通过。

关于为什么要保留这些判断，可继续阅读项目记录中的三个断点。需要整理自己的实践时，可在发布页填写记录；广场中的内容仍需逐条核对版本与验证证据，不能把公开发布视为已经复现。