# 知乎功能梳理与待办

更新时间：2026-06-15

## 当前同步状态

`vault/writing/` 中已经存在知乎真源文件：

- `vault/writing/知乎回答工作流.md`
- `vault/writing/知乎回答风格.md`
- `vault/writing/知乎功能梳理与待办.md`

这些文件位于 `vault -> /root/vault/Documents` 指向的 Obsidian vault 中。仓库侧保留入口文档和 slash command，vault 侧保留真正执行时要读的写作规则。

## 当前功能形态

知乎功能现在不走 `inkwell zhihu`，也不走 `inkwell write`。推荐路径是当前会话模型直接读取 vault 素材，按 Markdown 工作流生成待发布内容。

主要入口：

- `/zhihu-write`：用户给出知乎链接或问题文本、写作思路、素材文件或目录，生成定向回答。
- `/zhihu-explore`：用户给出素材目录，系统先生成主题图谱和搜索 query，再筛选候选问题。
- Codex/Hermes 通用入口：按 `docs/zhihu-workflow.md` 中的提示词直接调用 `vault/writing/知乎回答工作流.md`。

定向回答最少应产出：

- `question.md`
- `source-dossier.md`
- `brief.md`
- `draft.txt`
- `review.md`
- `final.txt`
- `publish-check.md`

主动探索额外应产出：

- `topic-map.md`
- `queries.md`
- `candidates.md`

发布规则：默认只生成待发布文本。发布、评论、点赞、关注、私信都必须等用户看过最终文本、目标 URL、账号和风险提示后明确确认。

## 已经具备的能力

- 定向回答流程已经定义清楚：问题上下文、素材提炼、brief、洞察卡、结构、起草、质检、发布检查。
- 主动探索流程已经定义清楚：主题图谱、搜索 query、候选问题、评分、进入定向回答。
- 风格规则已经独立出来：纯文本、匿名化、无引流、事实边界、避免公众号感和 AI 味。
- `CLAUDE.md`、`docs/writing-workflow.md` 和 `feature_list.json` 已经把 F10 从旧 CLI 管线改为 Agent/Markdown 工作流。
- 工程基线已通过：`bash scripts/check-architecture.sh` 和完整 pytest。

## 当前短板

- 还没有完成过留下全部产物的端到端知乎回答试跑。现有样例只到 `question.md`、`source-dossier.md`、`brief.md`。
- 知乎页面直接抓取容易遇到 403，流程需要更依赖用户粘贴问题正文、问题描述、高赞回答或本地缓存。
- `vault/zhihu/` 问题缓存目录还不存在，主动探索在无法联网时没有本地问题池可用。
- 素材路径解析还比较脆弱。现有试跑里用户指定的文章标题没有命中，最后只能用相邻素材兜底。
- 质检目前主要靠模型阅读规则，没有一个机械检查脚本去扫外链、引流语、Markdown 装饰、可疑身份信息和未授权数字。
- 没有成功样例库，后续模型只能读规则，缺少可模仿的最终回答和 publish-check 参考。

## P0 待办

1. 跑通一次真实定向回答。
   输入一个可粘贴的问题正文、明确写作思路和一个确定存在的素材目录，完整产出七个文件：`question.md`、`source-dossier.md`、`brief.md`、`draft.txt`、`review.md`、`final.txt`、`publish-check.md`。

2. 建立 `vault/zhihu/` 本地问题缓存。
   每个问题保存标题、URL、问题描述、高赞回答摘要、评论争议点和最后抓取时间。这样主动探索在知乎反爬或无网络时也能继续。

3. 改善素材路径命中。
   在工作流里明确：如果用户给的路径不存在，先用 `find` 和 `rg` 做标题模糊搜索，列出 3 到 5 个候选，让用户确认后再继续。

4. 补一个机械发布检查脚本。
   检查 `final.txt` 是否包含外链、账号名、Markdown 表格或标题装饰、明显引流语、禁用开头、可疑公司/职位暴露、没有来源的精确数字。

## P1 待办

1. 做一次主动探索试跑。
   用一个真实素材目录生成 `topic-map.md`、`queries.md`、`candidates.md`，至少拿到 5 个候选问题，并为最高优先级候选生成待发布回答。

2. 建立成功样例库。
   将 2 到 3 个质量合格的 `final.txt` 和 `publish-check.md` 放入 `vault/writing/Samples/知乎/`，供后续回答学习节奏和边界。

3. 给知乎产物加 smoke check。
   不调用 LLM，只检查任务目录是否包含必要文件、brief 是否有非共识判断、publish-check 是否包含发布门禁字段。

4. 更新 slash command 的异常处理。
   明确 403、素材不存在、brief 没有非共识判断、用户要求直接发布这四类情况的停机方式。

## P2 待办

1. 增加半自动导入工具。
   允许从浏览器复制的知乎页面文本中抽取标题、问题描述、回答摘要和评论争议点，写入 `vault/zhihu/`。

2. 形成候选问题评分历史。
   记录每次候选问题的评分、是否起草、是否发布、发布后反馈，慢慢调准主动探索的偏好。

3. 做发布前人工确认模板。
   固定展示目标 URL、账号、最终文本、身份风险、事实风险和建议操作，减少临门一脚时漏看风险。

## 更好状态的验收标准

- 连续 3 次 `/zhihu-write` 能完整产出七个文件，且 `final.txt` 不需要大改就能进入人工发布确认。
- 至少 1 次 `/zhihu-explore` 能从素材目录生成 5 个以上可用候选，并成功把 1 个候选转成完整待发布回答。
- 机械发布检查能拦住明显外链、引流语、Markdown 装饰、身份泄露和未授权数字。
- `vault/zhihu/` 有稳定的问题缓存格式，主动探索不再完全依赖实时访问知乎。
- `vault/writing/Samples/知乎/` 至少有 2 个合格样例，后续模型可以按样例校准节奏。

## 下一步建议

最小可执行动作是先做 P0 的第一项：选择一个真实知乎问题，粘贴标题和正文，指定一个确定存在的 vault 素材目录，完整跑一遍 `/zhihu-write`。这一步能最快暴露风格、事实边界、素材路径和发布检查里的真实问题。