换个对话就丢进度？给 AI Coding 留一张能核对的开发状态卡

AI SaaS 工程诊断实战（四）

一轮开发结束，留下"订单功能已完成"的总结。第二天换了对话，新的助手读到这句话，很容易从"继续优化"开始；但昨天的备注保存其实没通过检查，CSV 导出又早已明确延期。

如果把这两件事都压进一句总结，下一轮既可能跳过缺陷，也可能把延期项当成漏做。我的做法是让交接材料回答两个不同的问题：当前到底要求什么，当前有什么检查结果。

本文使用构造材料和一个状态映射小程序，演示交接卡怎样保留来源、版本和未知项。它不是能自动恢复全部聊天历史的工具，也没有读取任何客户项目。

先给材料分角色

这个案例只有三份决定来源：S01 要求确认状态写入、重复确认不重复登记；S02 追加备注保存；S03 明确延期 CSV 导出。另有两份 v1 的检查记录：E01 对确认状态及顺序重复操作检查通过；E02 对备注写入后读取检查失败。

这里的 S 是"为什么要求"，E 是"检查到了什么"。一份实现代码可以成为检查对象，却不能单独证明当时的需求；一句完成总结可以帮助定位线索，却不能替代运行记录。

工作项	当前范围	决定来源	证据	v1 状态
R01 确认与重复处理	是	S01	E01	指定样例通过
R02 保存备注	是	S02	E02	指定样例失败
R03 CSV 导出	延期	S03	无	延期

这样恢复出的下一步是修复 R02，而不是重新写所有功能。R03 仍可放入后续需求池，但没有新决定前，不应被助手自行恢复为当前范围。

卡片上至少保留这些位置

text 复制代码

任务 / 当前版本：订单演示 / 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 存在，不能检验来源是否真实、决定是否由有权的人作出。

python 复制代码

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))

交给下一轮时分两次做

第一轮先让助手只恢复范围：列出原始要求、已确认变更、延期项、冲突与缺材料项，暂不改代码。人工核对后，再进入第二轮，按工作项检查实现与实际结果。

可以直接使用下面的交接要求：

text 复制代码

先阅读状态卡与来源索引，不从现有代码反推需求。
列出当前范围、延期项和冲突；缺少来源的结论标待确认。
核对每份检查记录对应的版本和执行范围。
区分代码阅读结论、已运行结果与尚未执行的检查。
先给恢复结果，等我确认后再修改。

确认点应落到实际工作流程里。仅在提示词中写"不要越界"，不能保证工具就不会改动范围之外的文件。

状态清楚、只修一个很小的问题时，不需要把所有历史重新整理一遍。对话多次转向、需求发生冲突、准备阶段验收时，这张卡才特别有用。交接的目标是让下一轮知道从哪里继续，并知道哪些话还不能相信。

------ Linksass｜AI SaaS 独立开发者。方法参考个人知识库中关于任务状态、独立检查与证据边界的整理，AI 辅助制作；全部案例与记录均为教学构造。