tc-state

name	tc-state
description	TC 创业状态存档工具。用户说“/tc-state”“保存这次创业判断”“记住当前方案”“恢复上次 TC 进度”“继续上次创业问题”“列出 TC 存档”“生成阶段报告”或明确要求把已脱敏市场证据交给 TC 知识候选时使用。把确认的问题、判断、行动和证据保存到本机，或在逐次授权后导出本机候选；不自动上传，不替用户保存敏感原文。

TC State｜创业状态

一句话说明

这是 TC 的“游戏存档”。今天做到一半可以保存；下次回来不用从第一关重新讲。

只处理五种请求

1. 保存：把当前已经确认的创业判断和下一步写进本机存档。
2. 恢复：读取某个项目最近一次存档，并从下一步继续。
3. 列表：列出本机有哪些 TC 项目和存档。
4. 报告：把同一项目的多次存档合成阶段报告。
5. 证据导出：用户逐次明确同意后，导出不含项目名、联系人和完整事实清单的本机候选文件，交给 tc-knowledge 人工复核。

不负责重新诊断、写文案或代替 tc-action 设计行动。发现问题定义还没有确认时，先回到 /tc 或 tc-diagnosis。

默认保存位置

~/.tc/projects/<项目名>/
├── current.md
├── current.json
├── sessions/
│   ├── 20260721T153000123456Z-标题.md
│   └── 20260721T153000123456Z-标题.json
└── reports/
    └── 20260721T160000123456Z-阶段报告.md

所有文件默认只写在用户本机。不要声称作者可以看到这些文件。

保存前的边界

• 只有用户明确说要保存、记住或建立进度时才写文件。
• 保存前用一句话告诉用户将写入本机 ~/.tc/。
• 默认不保存姓名、手机号、邮箱、账号密码、访问令牌、私聊全文、客户名单、合同原文和未公开商业机密。
• 需要保留人物关系时，用“合伙人 A”“客户 B”等代号。
• 用户要求保存敏感信息时，先提醒这是明文 Markdown，再让用户决定是否继续。
• 不自动上传到 GitHub、飞书、邮箱或其他网络服务。
• “同意保存状态”不等于“同意导出知识候选”；证据导出必须单独取得当次授权。

一份合格存档包含什么

只保存已经影响判断的内容：

• problem_definition：这次真正解决什么；
• confirmed_facts：已经发生、能核对的事实；
• decision：当前选择；
• tradeoff：这个选择必须放弃或承担什么；
• rejected_directions：这次明确不做什么；
• assumptions：仍待市场验证的假设；
• next_action：下一项最小动作；
• success_metric：什么结果算有效；
• evidence：已经带回的用户原话、报价、付款、交付或毛利证据；
• next_skill：下次最可能进入 /tc、tc-copy 或 tc-action 中哪一个。

没有 problem_definition、decision 或 next_action 时，不要伪造；告诉用户还缺哪一项。

使用脚本

脚本只依赖 Python 标准库：

python3 scripts/tc_state.py save --payload /tmp/tc-state.json
python3 scripts/tc_state.py list
python3 scripts/tc_state.py restore --project 项目代号
python3 scripts/tc_state.py report --project 项目代号
python3 scripts/tc_state.py export-evidence \
  --project 项目代号 \
  --output /tmp/tc-evidence-candidate.json \
  --consent

在 Agent 环境中执行时，先把结构化内容写入临时 JSON，再把路径传给 --payload。不要把用户原文直接拼进 shell 命令，避免引号和命令替换造成错误。

最小 JSON：

{
  "project": "创业主线",
  "title": "确定九十天唯一主线",
  "source_skill": "tc",
  "status": "active",
  "problem_definition": "在不影响现有现金流的前提下，选出未来九十天唯一主线。",
  "confirmed_facts": ["已有公开内容渠道", "当前同时处理多个方向"],
  "decision": "只验证一个已有人付费的服务产品。",
  "tradeoff": "暂时不新开赛道。",
  "rejected_directions": ["同时测试三个新项目"],
  "assumptions": ["现有咨询里存在可重复需求"],
  "next_action": "整理最近十次真实咨询，统计重复问题。",
  "success_metric": "七天内向五位同类客户正式报价。",
  "evidence": [],
  "next_skill": "tc-action"
}

恢复后的回复

不要把整份 Markdown 原样倾倒给用户。先用四行恢复上下文：

上次解决的问题：……
上次决定：……
还没验证的假设：……
下一步：……

然后只问一句：

这一步做了吗？把结果直接发我，没做也可以说真实原因。

用户带回结果后，回到 /tc 更新判断；需要拆动作时进入 tc-action。

市场证据进入知识候选

只有用户明确说“把这次结果作为知识候选”时才执行：

1. 先说明只生成本机文件，不上传；
2. 使用 export-evidence --consent 导出；
3. 检查导出内容，确认没有姓名、联系方式、客户、链接、账号、合同和商业机密；
4. 再交给 tc-knowledge candidate-add 保存为本机 L1 候选。

导出默认只保留：问题定义、当前判断、下一步、有效标准和用户主动记录的证据。脚本会移除常见邮箱、手机号、链接和凭据格式，但自动脱敏不能替代人工复核。

一次状态或一个成功案例不能升级成稳定方法。只有多个独立案例出现相近场景、动作和结果，并通过许可、隐私、反例与副作用检查，才允许由维护者人工提炼。

阶段报告

同一项目至少有两次存档时再生成报告。报告重点是变化，不是拼接聊天记录：

• 问题定义怎么变了；
• 哪些假设被证实或推翻；
• 做过哪些动作；
• 拿到哪些市场证据；
• 哪些方向被停止；
• 下一阶段唯一问题是什么。

回复格式

保存成功：

已保存到本机：<路径>
下次输入“/tc 恢复 <项目名>”就能接着做。
下一步仍是：<动作>

失败时说清具体缺什么或哪个文件无法读取，不要假装已经保存。