| name | tc-state |
| description | TC 创业状态存档工具。用户说“/tc-state”“保存这次创业判断”“记住当前方案”“恢复上次 TC 进度”“继续上次创业问题”“列出 TC 存档”“生成阶段报告”或明确要求把已脱敏市场证据交给 TC 知识候选时使用。把确认的问题、判断、行动和证据保存到本机，或在逐次授权后导出本机候选；不自动上传，不替用户保存敏感原文。 |
TC State｜创业状态
一句话说明
这是 TC 的“游戏存档”。今天做到一半可以保存；下次回来不用从第一关重新讲。
只处理五种请求
- 保存：把当前已经确认的创业判断和下一步写进本机存档。
- 恢复：读取某个项目最近一次存档，并从下一步继续。
- 列表：列出本机有哪些 TC 项目和存档。
- 报告：把同一项目的多次存档合成阶段报告。
- 证据导出：用户逐次明确同意后，导出不含项目名、联系人和完整事实清单的本机候选文件，交给
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。
市场证据进入知识候选
只有用户明确说“把这次结果作为知识候选”时才执行：
- 先说明只生成本机文件，不上传；
- 使用
export-evidence --consent 导出；
- 检查导出内容，确认没有姓名、联系方式、客户、链接、账号、合同和商业机密；
- 再交给
tc-knowledge candidate-add 保存为本机 L1 候选。
导出默认只保留：问题定义、当前判断、下一步、有效标准和用户主动记录的证据。脚本会移除常见邮箱、手机号、链接和凭据格式，但自动脱敏不能替代人工复核。
一次状态或一个成功案例不能升级成稳定方法。只有多个独立案例出现相近场景、动作和结果，并通过许可、隐私、反例与副作用检查，才允许由维护者人工提炼。
阶段报告
同一项目至少有两次存档时再生成报告。报告重点是变化，不是拼接聊天记录：
- 问题定义怎么变了；
- 哪些假设被证实或推翻；
- 做过哪些动作；
- 拿到哪些市场证据；
- 哪些方向被停止；
- 下一阶段唯一问题是什么。
回复格式
保存成功：
已保存到本机：<路径>
下次输入“/tc 恢复 <项目名>”就能接着做。
下一步仍是：<动作>
失败时说清具体缺什么或哪个文件无法读取，不要假装已经保存。
