AI SaaS 工程诊断实战（四）
一轮开发结束，留下“订单功能已完成”的总结。第二天换了对话，新的助手读到这句话，很容易从“继续优化”开始；但昨天的备注保存其实没通过检查，CSV 导出又早已明确延期。
如果把这两件事都压进一句总结，下一轮既可能跳过缺陷，也可能把延期项当成漏做。我的做法是让交接材料回答两个不同的问题：当前到底要求什么，当前有什么检查结果。
本文使用构造材料和一个状态映射小程序，演示交接卡怎样保留来源、版本和未知项。它不是能自动恢复全部聊天历史的工具，也没有读取任何客户项目。
先给材料分角色
这个案例只有三份决定来源：S01 要求确认状态写入、重复确认不重复登记；S02 追加备注保存；S03 明确延期 CSV 导出。另有两份 v1 的检查记录：E01 对确认状态及顺序重复操作检查通过；E02 对备注写入后读取检查失败。
这里的 S 是“为什么要求”，E 是“检查到了什么”。一份实现代码可以成为检查对象，却不能单独证明当时的需求；一句完成总结可以帮助定位线索，却不能替代运行记录。
| 工作项 | 当前范围 | 决定来源 | 证据 | v1 状态 |
|---|---|---|---|---|
| R01 确认与重复处理 | 是 | S01 | E01 | 指定样例通过 |
| R02 保存备注 | 是 | S02 | E02 | 指定样例失败 |
| R03 CSV 导出 | 延期 | S03 | 无 | 延期 |
这样恢复出的下一步是修复 R02，而不是重新写所有功能。R03 仍可放入后续需求池，但没有新决定前，不应被助手自行恢复为当前范围。
卡片上至少保留这些位置
任务 / 当前版本：订单演示 / v1
当前目标：确认状态、重复处理、备注保存
本轮延期：CSV 导出 → S03
材料入口：S01 / S02 / S03 → 实际文件或消息位置
检查结果：R01 → E01；R02 → E02
仍未验证：页面、权限、并发、重启后的读取
下一步：只处理 R02，再检查受影响行为
待确认：规则是否有变化；缺少材料的部分继续记未知
真实项目中的“入口”必须能定位，不只写一句“见聊天”。文件可以带提交版本，聊天决定可以保留消息链接及上下文；涉及私密材料时，卡片只在相应授权范围内使用，不把完整记录随意发到外部服务。
这张卡是索引，不是原始材料的替代品。它应该短到下一轮愿意读，又具体到重要结论有处可查。
换了版本，旧通过不自动变成新通过
程序里有个刻意保守的规则：只有证据版本与当前版本相同，才采用 pass 或 fail；版本不同先显示 unverified。延期项由范围决定保持 deferred，不因代码版本变化自动变成未完成缺陷。
同样一组记录，v1 的结果是 pass、fail、deferred；把当前版本改为 v2 而没有补新证据，结果变成 unverified、unverified、deferred。
实际工程可以更精细：有些改动不影响旧证据，可由负责人评估后记录复用依据。但不能省掉这一步，直接把历史的“通过”搬到新版本。这里默认失效，是为了让示例足够清楚，不是要求每改一句文案都重测整个系统。
一个能运行的交接状态演示
保存为 demo.py，运行 python demo.py。代码使用标准库，在 Python 3.12 本地执行过。它只验证状态映射及来源 ID 存在，不能检验来源是否真实、决定是否由有权的人作出。
import json
# All records below are constructed teaching fixtures.
sources = {
'S01': '确认状态写入；重复确认不重复登记事件',
'S02': '追加备注保存',
'S03': 'CSV导出延期',
}
evidence = {
'E01': {'version': 'v1', 'result': 'pass', 'scope': '顺序确认两次，状态与事件读取'},
'E02': {'version': 'v1', 'result': 'fail', 'scope': '备注写入后读取为空'},
}
items = [
{'id': 'R01', 'source': 'S01', 'requirement': '确认与重复处理', 'in_scope': True, 'evidence': 'E01'},
{'id': 'R02', 'source': 'S02', 'requirement': '保存备注', 'in_scope': True, 'evidence': 'E02'},
{'id': 'R03', 'source': 'S03', 'requirement': 'CSV导出', 'in_scope': False, 'evidence': None},
]
def restore(version):
result = []
for item in items:
assert item['source'] in sources
record = evidence.get(item['evidence'])
if not item['in_scope']:
status = 'deferred'
elif record is None or record['version'] != version:
status = 'unverified'
else:
status = record['result']
result.append(dict(id=item['id'], requirement=item['requirement'],
source=item['source'], status=status,
evidence=item['evidence']))
return result
if __name__ == '__main__':
before, after = restore('v1'), restore('v2')
assert [x['status'] for x in before] == ['pass', 'fail', 'deferred']
assert [x['status'] for x in after] == ['unverified', 'unverified', 'deferred']
print(json.dumps({'v1': before, 'v2_without_new_evidence': after}, ensure_ascii=False, indent=2))
交给下一轮时分两次做
第一轮先让助手只恢复范围：列出原始要求、已确认变更、延期项、冲突与缺材料项，暂不改代码。人工核对后，再进入第二轮，按工作项检查实现与实际结果。
可以直接使用下面的交接要求：
先阅读状态卡与来源索引，不从现有代码反推需求。
列出当前范围、延期项和冲突；缺少来源的结论标待确认。
核对每份检查记录对应的版本和执行范围。
区分代码阅读结论、已运行结果与尚未执行的检查。
先给恢复结果，等我确认后再修改。
确认点应落到实际工作流程里。仅在提示词中写“不要越界”，不能保证工具就不会改动范围之外的文件。
状态清楚、只修一个很小的问题时，不需要把所有历史重新整理一遍。对话多次转向、需求发生冲突、准备阶段验收时，这张卡才特别有用。交接的目标是让下一轮知道从哪里继续，并知道哪些话还不能相信。
—— Linksass｜AI SaaS 独立开发者。方法参考个人知识库中关于任务状态、独立检查与证据边界的整理，AI 辅助制作；全部案例与记录均为教学构造。
