一人公司的知识库，不是把行业文章、客户聊天记录和产品日志集中存起来，而是把这些碎片逐步加工成能够支持决策、交付和复盘的知识资产。适合个体创业者的做法，是先用低成本方式捕捉信息，再通过双向链接把“发生过什么”连接到“为什么这样做”和“下次如何复用”。

先明确：知识库要服务哪些经营任务

一人公司的知识库，至少应该帮助你完成四件事：

• 判断方向：客户正在反复提出什么问题，哪些需求值得验证。
• 改进产品或服务：某次迭代解决了什么问题，结果是否支持继续投入。
• 提高交付效率：过去做过的方案、流程和案例，能否缩短下一次交付时间。
• 减少重复思考：遇到相似客户、相似故障或相似决策时，可以快速找到依据。

因此，不要一开始就追求复杂的分类体系。先围绕经营流程建立知识资产的流转：

捕捉碎片 → 补充上下文 → 提炼判断 → 关联主题 → 形成可复用资产 → 在业务中验证

如果一条笔记没有进入这个流程，它可能只是资料收藏，而不是知识库的一部分。

Obsidian 和 Logseq 如何分工

Obsidian 和 Logseq 都可以处理本地 Markdown 文件，但两者的基本组织单元不同：Obsidian 更偏向以页面为单位的文档型双向链接，Logseq 更偏向以块为单位的大纲型双向链接。这个差异决定了它们适合放在工作流的不同位置。

工具	更适合的任务	对一人公司的价值	上手注意点
Obsidian	长文、项目文档、主题笔记、方案沉淀	便于组织完整知识和持续写作	需要自己设计页面命名与链接规则
Logseq	日记、会议记录、任务清单、快速捕捉	适合把一天的经营活动连续记录下来	块很多时要及时提炼，避免只留下流水账
两者配合	Logseq 记录过程，Obsidian 整理成果	把即时记录与长期资产分开	先备份，再测试文件兼容性与同步方式

一种实用分工是：

1. 在 Logseq 的日记中记录当天的客户沟通、灵感、待办和产品观察。
2. 对有价值的内容添加页面链接，例如 [[客户需求]]、[[定价策略]] 或 [[产品迭代]]。
3. 在 Obsidian 中打开这些主题页面，补充背景、判断、证据和下一步行动。
4. 将已经验证过的内容整理成案例、流程、模板或决策记录。

社区经验中，Obsidian 与 Logseq 可以围绕本地 Markdown 文件尝试共用知识库，但具体兼容性会受到语法、文件路径、同步工具和版本变化影响。实践前应先复制一份库进行测试，并尽量以页面链接为主，少依赖特定工具的块引用。可参考 Obsidian 中文论坛关于两者联用的讨论 和 少数派的联用经验。

一套适合一人公司的双向链接架构

建议采用“入口页 + 主题页 + 过程页 + 资产页”的结构，而不是把所有内容都按文件夹堆放。

1. 入口页：经营总览

入口页不是存放所有内容的地方，而是经营导航。可以设置以下链接：

# 经营总览

## 当前目标
- [[本季度经营目标]]
- [[本周重点]]

## 正在推进
- [[项目-A]]
- [[产品-B]]
- [[客户-C]]

## 需要判断
- [[是否增加某项服务]]
- [[客户反馈是否代表普遍需求]]

## 常用资产
- [[报价模板]]
- [[客户访谈提纲]]
- [[交付检查清单]]

入口页只保留当前真正需要访问的内容。已经结束的项目可以移到“历史项目”页面，避免首页变成长期不更新的链接墓地。

2. 主题页：承载长期问题

主题页回答“我长期在研究或经营什么”。例如：

• [[独立开发产品定价]]
• [[自由职业客户筛选]]
• [[AI 自动化交付]]
• [[内容获客]]
• [[客户留存]]

主题页不必一次写完。每次记录客户反馈、行业资讯或产品变化时，只要在相关内容中链接主题页，反向链接就会逐渐形成该主题的资料入口。

主题页建议采用以下结构：

# 独立开发产品定价

## 当前判断
针对目标客户，按结果而不是按功能收费更容易解释价值，但仍需通过访谈和报价测试验证。

## 关键证据
- [[客户-C-报价沟通-2025-06-12]]
- [[产品-B-试用反馈-2025-06-15]]
- [[竞品定价观察-2025-06]]

## 已验证做法
- [[报价模板-按结果分层]]

## 未解决问题
- 客户是否愿意为持续维护单独付费？
- 哪项服务内容最容易被理解为可量化结果？

## 相关主题
- [[客户筛选]]
- [[服务范围控制]]
- [[收入结构]]

这里的关键不是链接数量，而是让每条链接都说明它与主题的关系：它是证据、反例、行动、结果，还是待验证假设。

3. 过程页：保留真实经营痕迹

过程页记录事情如何发生，适合放在日记、项目日志和客户沟通记录中：

• 客户访谈记录
• 需求评审
• 产品迭代日志
• 交付过程
• 销售跟进
• 失败复盘
• 每周经营回顾

过程页不必写成完整文章，但要包含足够的上下文。建议使用以下模板：

# 客户-C-需求沟通-2025-06-12

## 场景
客户希望减少人工整理周报的时间。

## 原话或事实
- 当前每周需要手动汇总多个表格。
- 客户最在意结果是否能直接交给管理层使用。
- 暂未确认愿意支付的预算范围。

## 我的判断
这可能不是单纯的数据整理需求，而是“快速形成管理汇报”的交付需求。

## 关联
- [[客户需求]]
- [[自动化交付]]
- [[产品-B-需求池]]

## 下一步
- 询问客户当前周报的固定字段。
- 用一份样例验证自动生成结果。
- 不在验证前承诺完整定制开发。

“原话或事实”和“我的判断”要分开。这样在几周后回看时，你能知道哪些内容来自客户，哪些内容是自己当时的推测。

4. 资产页：沉淀可以再次使用的成果

知识资产的标准不是“写得很完整”，而是下次遇到类似任务时能否直接调用。适合沉淀为资产的内容包括：

• 报价单和服务说明
• 客户访谈提纲
• 产品需求判断标准
• 交付流程
• 常见问题答复
• 故障排查清单
• 内容选题库
• 失败案例与规避条件
• 自动化脚本和提示词

资产页最好写清楚适用条件，不要把一次性的做法伪装成通用方法：

# 客户访谈提纲-自动化需求

## 适用场景
适用于已经有人工流程、但尚未明确自动化边界的潜在客户。

## 访谈问题
1. 目前流程由谁负责？
2. 每周重复发生多少次？
3. 哪一步最容易出错？
4. 出错后会带来什么影响？
5. 现有工具为什么没有解决？
6. 如果改进成功，客户如何判断结果？

## 使用限制
- 不适用于需求尚未发生过的潜在场景。
- 不应只根据客户表达的“想要 AI”判断真实需求。
- 访谈结论仍需通过样例或小范围交付验证。

## 来源
- [[客户-C-需求沟通-2025-06-12]]
- [[客户-D-需求沟通-2025-06-18]]

把三类碎片加工成知识资产

行业资讯：从“看到”变成“影响判断”

不要只保存文章标题和链接。至少补充三项内容：

1. 这条信息涉及哪个主题？
2. 它可能影响我的哪项业务判断？
3. 我是否需要采取行动，或者继续观察？

模板可以这样写：

# 行业资讯-某领域工具更新-2025-06

## 信息摘要
用自己的话概括事实，不复制原文。

## 可能影响
- 可能影响 [[产品-B]] 的功能优先级。
- 暂时不能据此判断市场需求已经扩大。

## 我的判断
目前只有单条信息，不能作为投入依据。

## 下一步
继续收集客户反馈，并在下次访谈中验证相关场景。

## 来源
- [原始页面](https://example.com)

对于政策、价格、产品功能和行业数据等容易变化的内容，必须记录来源和查看日期。没有可靠来源或无法确认时，应明确标注“待核实”，不要把推测写成结论。

客户反馈：从“客户说了什么”变成“问题模式”

客户原话很重要，但原话本身不是需求结论。你可以按照以下顺序处理：

• 记录客户在什么场景下遇到问题。
• 区分客户描述的现象和你推断的原因。
• 将反馈链接到已有主题。
• 与其他客户记录进行对比。
• 形成待验证假设，而不是立即排进开发计划。

例如，三个客户都说“希望有更智能的功能”，这只能说明表达相似，不能直接说明他们愿意为同一项功能付费。你还需要继续追问：他们现在如何解决、问题发生频率、造成什么损失，以及是否愿意改变现有流程。

产品迭代：从“做过什么”变成“学到了什么”

产品日志不要只写：

- 增加导出功能
- 修复登录问题
- 优化页面速度

更有价值的记录方式是：

# 产品-B-迭代-2025-06-20

## 触发原因
两位试用用户无法把结果交给团队成员继续处理。

## 迭代内容
增加可下载的结构化结果。

## 假设
如果结果更容易交接，用户会更愿意把工具纳入现有流程。

## 观察指标
- 是否有人完成下载
- 是否有人再次使用
- 是否减少重复沟通

## 结果
上线后继续观察，当前样本不足。

## 关联
- [[客户-C-需求沟通-2025-06-12]]
- [[产品-B-激活路径]]
- [[交付结果可复用性]]

这种记录会把“功能”连接到“问题、假设和结果”，方便你判断哪些迭代值得继续，哪些只是忙碌感。

用链接代替过度分类

文件夹适合表达存储位置，双向链接更适合表达业务关系。同一条客户记录可能同时属于：

• [[客户需求]]
• [[产品验证]]
• [[自动化交付]]
• [[定价策略]]

如果只把它放进“客户资料”文件夹，之后从产品或定价角度回顾时很难找到。链接则允许一条记录进入多个经营视角。

建议遵循三条规则：

用页面链接表达重要概念

凡是会反复出现、需要持续积累的概念，都可以建立页面链接，例如客户类型、业务问题、产品模块和经营指标。

用标签表达状态或属性

标签适合表达有限且稳定的状态，例如：

#待验证
#已采用
#需复盘
#客户反馈
#产品迭代

不要为每个细节创建标签，否则标签会变成另一套难以维护的分类系统。

每条链接都尽量说明关系

相比单独写：

[[定价策略]]

更推荐写成：

这次报价暴露了[[按结果定价]]仍需要更多客户验证。

自然语言中的链接更容易被未来的自己理解，也更适合直接转化为文章、方案或决策记录。

每天、每周、每月怎么维护

每天：只做轻量捕捉

当天只需要完成三件事：

• 把重要沟通和观察记录下来。
• 给内容加上一个或两个主题链接。
• 标出需要后续处理的判断或任务。

不要在信息刚出现时强迫自己完成完美归档。记录的连续性比当天整理得漂亮更重要。

每周：提炼一次判断

每周选择一个固定时间，处理本周的过程记录：

• 哪些客户问题重复出现？
• 哪些判断被事实支持或推翻？
• 哪些内容可以沉淀为模板？
• 哪些项目应该停止、延期或缩小范围？
• 哪些待办其实只是没有明确的决策？

每周至少产出一页“经营回顾”，并链接到相关客户、项目和产品页面。

每月：清理失效知识

每月检查：

• 过期的价格、功能和政策信息是否仍然有效。
• 哪些模板已经不适用于当前业务。
• 哪些主题页只有收藏，没有自己的判断。
• 哪些项目已经结束但仍占据入口页。
• 哪些知识资产真的在交付或销售中被使用过。

知识库不是越大越好。能够减少一次重复沟通、缩短一次交付准备、避免一次错误决策的内容，才值得长期维护。

从零开始的七天搭建计划

如果你还没有知识库，可以按以下顺序开始：

1. 第一天：确定工具

只选择 Obsidian 或 Logseq 作为主工具。需要大量日记和任务记录时，可先从 Logseq 开始；需要长文、项目文档和主题沉淀时，可先从 Obsidian 开始。

1. 第二天：建立四类页面

创建经营总览、主题页、过程页和资产页，不要先安装大量插件。

1. 第三天：建立三个模板

分别用于客户沟通、产品迭代和每周复盘。

1. 第四天：迁移最近两周的记录

不要一次搬运全部历史资料，只处理仍然与当前业务有关的内容。

1. 第五天：补充双向链接

为每条重要记录连接到主题页，并检查反向链接是否能帮助你找到相关上下文。

1. 第六天：提炼一项资产

从真实记录中整理出一个可复用模板、流程或检查清单。

1. 第七天：进行一次经营回顾

写下本周最重要的三个判断，以及下周需要验证的一个假设。

完成这一轮后，再决定是否需要增加搜索、数据库视图、自动化或 AI 辅助。工具的复杂度应当服从经营任务，而不是让经营任务迁就工具。

最后的检查标准

一个能真正服务一人公司的知识库，应该满足以下条件：

• 你能在几分钟内找到某个客户问题的原始记录。
• 你能区分事实、判断、假设和最终决策。
• 你能把一次交付经验整理成下一次可调用的资产。
• 你能从产品迭代记录中看到问题与结果，而不只是功能清单。
• 你能通过反向链接发现不同客户、项目和主题之间的重复模式。
• 你愿意持续维护，而不是只有搭建当天觉得兴奋。

Obsidian 和 Logseq 只是承载方式。真正决定知识库价值的，是你是否持续把经营过程中的碎片，转化为可验证、可连接、可复用的结构化思考。