这次我们来看一个很有意思的观点Garry Tan 提出的“未来整个创业公司就是 Markdown 文件”。这不是一个具体的软件或模型而是一个关于软件开发、团队协作和知识管理未来形态的前沿理念。对于开发者、产品经理和创业者来说理解这个观点意味着理解下一代工具如何重塑我们的工作流。简单来说这个观点认为一个公司的核心资产——产品需求、设计文档、代码、运营策略、甚至财务模型——都可以被结构化为 Markdown 文件并通过现代工具链如 Git、AI 代理、自动化工作流进行管理、协作和演化。它解决的核心问题是信息孤岛、工具割裂和协作低效。如果你厌倦了在 Confluence、Notion、Figma、Jira、GitHub 和一堆 Excel 表格之间来回切换那么这个理念值得你深入了解。本文不会介绍一个可以“一键启动”的软件但会深入拆解这个理念背后的技术栈、实践方法和工具链。我们将探讨Markdown 为何能成为“单一事实来源”如何用现有的工具如 Obsidian、VS Code、Git构建一个以 Markdown 为中心的创业公司知识库以及 AI如 Claude、GPT如何作为“员工”直接读取和操作这些 Markdown 文件实现自动化。无论你是想优化个人工作流还是为团队寻找更高效的协作范式这篇文章都将提供一套可落地的思路和具体操作指南。1. 核心能力速览Markdown 作为公司核心的可行性分析首先我们需要明确“创业公司即 Markdown 文件”不是一个已经打包好的产品而是一个架构理念和最佳实践的集合。它的“核心能力”体现在对信息处理方式的根本性变革上。能力项说明与解读核心理念将公司所有非代码类知识资产想法、规划、文档、数据以纯文本 Markdown 格式存储实现人机皆可读、可版本控制、可自动化处理。技术门槛低。主要依赖通用文本编辑器、Git 和命令行工具无需特定商业软件许可。核心工具链编辑器VS Code, Obsidian版本控制GitCLI 工具AI 接口OpenAI, Anthropic。“启动”方式从建立一个 Git 仓库开始用 Markdown 撰写第一份产品构想文档。“接口”能力极强。Markdown 是纯文本可通过脚本、AI API 进行批量读取、分析、转换和生成。“批量任务”支持原生支持。可通过 Shell/Python 脚本对整个目录的 Markdown 文件进行批量操作如统计、搜索、格式转换、内容同步。适合场景初创团队特别是技术背景强的、远程异步协作、个人知识管理、需要高度自动化和可追溯性的项目。这个理念的吸引力在于其极简和强大的二元性格式简单到用记事本就能写但生态强大到可以连接整个现代开发与AI工具链。2. 适用场景与使用边界谁适合采用这种模式技术驱动的初创公司工程师文化浓厚习惯使用 Git追求效率和自动化。小型远程团队需要清晰的异步文档协作减少会议沟通。独立开发者和创作者希望统一管理项目文档、日志、内容草稿和待办事项。追求“可编程知识库”的团队希望用代码的方式管理文档例如自动生成周报、同步数据到不同平台。它能解决什么问题信息碎片化设计稿在 Figma需求在 Jira会议纪要在 Google Docs最终谁是最新版本协作上下文丢失新成员入职需要翻看无数个链接和历史聊天记录才能了解项目全貌。知识资产无法复用过去的项目复盘、市场分析无法被轻易搜索和提取到新项目中。流程自动化困难因为数据被锁在封闭的 SaaS 工具里难以与内部工具链集成。它的边界与挑战非技术成员上手成本对于不熟悉 Markdown 语法、Git 基本操作的成员需要一定的学习和适应期。富媒体内容处理图片、视频等二进制文件仍需外部存储Markdown 中仅保存链接。但这恰好符合“关注点分离”的原则。复杂的表单和数据库场景对于需要强结构化、实时协作编辑的数据如复杂的财务表格专门的工具可能更合适。但 Markdown 表格和 YAML Front Matter 可以解决大部分轻度结构化数据需求。企业级权限与审计原生 Git 的权限管理不如专业企业级文档平台精细需要搭配 Git 托管平台如 GitHub, GitLab的团队功能。重要提醒此模式强调信息的开放性和可操作性但同样需要注意数据安全。涉及敏感信息如商业机密、个人隐私的文档必须通过私有仓库、加密工具或严格的访问控制来管理。3. 环境准备与前置条件构建一个“Markdown 公司”不需要高性能 GPU但对工具链的熟悉程度有要求。以下是你的“数字办公环境”清单核心编辑器任选其一VS Code微软出品插件生态极其丰富内置 Git 管理适合开发者。必装插件Markdown All in One,Markdown Preview Enhanced,Paste Image方便插入本地图片。Obsidian以“双向链接”和“知识图谱”著称所有数据以本地 Markdown 文件存储非常适合构建相互关联的知识库。社区插件强大。Vim/Neovim 或 Emacs适合终端爱好者通过配置可以达到极高的编辑效率。版本控制系统Git必备技能。不仅是代码文档的每一次修改都应该提交并附上有意义的注释。Git 图形化客户端可选如 GitHub Desktop, Sourcetree方便不习惯命令行的成员进行提交、拉取和查看历史。文件同步与备份Git 托管平台GitHub, GitLab, Gitee。用于远程备份、团队协作和 Pull Request 审阅流程。同步盘可选如 iCloud Drive, Dropbox, Syncthing。用于在多设备间同步 Obsidian 库等。命令行环境Bash/Zsh/Fish在 Unix-like 系统macOS, Linux或 WSLWindows上命令行是执行批量操作和自动化脚本的关键。核心命令行工具find,grep,sed,awk。用于快速搜索和转换文本。AI 助手接入可选但推荐OpenAI API 或 Anthropic Claude API用于让 AI 理解、总结、改写或基于你的 Markdown 知识库生成内容。相关脚本工具如llm(Simon Willison 的命令行工具)可以方便地在终端与 AI 交互。4. 安装部署与启动方式建立你的第一个“公司仓库”这里没有docker-compose up你的“启动”命令是git init。第一步规划仓库结构在开始写任何内容之前先设计一个清晰的文件目录结构。这是一个模拟的创业公司仓库示例your-startup-repo/ ├── README.md # 公司/项目总览 ├── VISION.md # 愿景与使命 ├── STRATEGY/ │ ├── Product-Roadmap.md # 产品路线图 │ ├── Go-to-Market.md # 市场进入策略 │ └── Competitive-Analysis.md # 竞争分析 ├── PRODUCT/ │ ├── PRD/ # 产品需求文档 │ │ ├── Epic-1-Feature-A.md │ │ └── Epic-2-Feature-B.md │ ├── Design/ # 设计文档与决策记录 │ │ └── Design-System-Decisions.md │ └── Specs/ # 技术规格 │ └── API-Spec-v1.md ├── ENGINEERING/ │ ├── ADRs/ # 架构决策记录 (Architecture Decision Records) │ │ └── 2024-01-01-use-nextjs.md │ └── Runbooks/ # 运维手册 │ └── Deployment-Procedure.md ├── OPERATIONS/ │ ├── OKRs/ # 目标与关键成果 │ │ └── Q1-2024.md │ ├── Processes/ # 工作流程 │ │ └── How-We-Hire.md │ └── Meetings/ # 会议纪要 │ └── 2024-01-15-Weekly-All-Hands.md ├── MARKETING/ │ └── Content-Calendar.md ├── assets/ # 图片等静态资源 │ └── product-screenshot-v1.png └── scripts/ # 自动化脚本 ├── sync_to_notion.py # 示例将 Markdown 同步到 Notion └── generate_weekly_report.sh # 示例生成周报第二步初始化仓库并提交# 1. 创建目录并进入 mkdir my-startup-wiki cd my-startup-wiki # 2. 初始化 Git 仓库 git init # 3. 创建上述目录结构 (可以使用 mkdir -p 命令批量创建) mkdir -p STRATEGY PRODUCT/PRD PRODUCT/Design PRODUCT/Specs ENGINEERING/ADRs ENGINEERING/Runbooks OPERATIONS/OKRs OPERATIONS/Processes OPERATIONS/Meetings MARKETING assets scripts # 4. 创建第一个核心文件README.md echo # My Startup README.md echo ## Vision README.md echo To build the future with Markdown. README.md # 5. 进行首次提交 git add . git commit -m Initial commit: Repository structure and README第三步连接远程仓库以 GitHub 为例在 GitHub 上创建一个新的空仓库不要初始化 README。按照 GitHub 的提示将本地仓库与远程仓库关联。git remote add origin https://github.com/yourusername/your-startup-repo.git git branch -M main git push -u origin main至此你的“公司”已经“启动”了。所有后续的思考、决策和创作都将在这个结构化的文本仓库中发生。5. 功能测试与效果验证让 Markdown 真正工作起来仅仅存储文本是不够的我们需要验证这套体系如何解决实际问题。下面通过几个具体场景来测试。测试 1高效创作与链接 —— 撰写一份产品需求文档PRD目的验证用 Markdown 写复杂文档的可行性并利用双向链接建立文档网络。操作步骤在PRODUCT/PRD/目录下创建Epic-1-User-Onboarding.md。使用 Markdown 语法撰写并融入一些高级实践--- title: 用户引导流程优化 (Epic #1) status: In Progress author: alice created: 2024-01-15 related: - ../Design/Onboarding-UI-Sketch.md - ../../STRATEGY/Go-to-Market.md#target-users --- # 用户引导流程优化 (Epic #1) ## 背景与问题 目前的新用户激活率仅为 30%。根据 [[../../OPERATIONS/Meetings/2024-01-10-User-Research-Summary.md]] 中的访谈问题主要出在... ## 目标 - **主要目标**将新用户激活率提升至 50%。 - **成功指标**见 [[../../OPERATIONS/OKRs/Q1-2024.md#objective-2]]。 ## 用户故事 1. 作为一个新用户我希望...以便于... 2. [故事2]... ## 功能需求 ### F1: 个性化欢迎教程 - **描述**根据用户注册来源显示定制化的第一步教程。 - **设计参考**  - **技术关联**此功能依赖于 [[../../ENGINEERING/ADRs/2024-01-01-use-nextjs.md]] 中决定的前端框架。 ## 非功能需求 - 页面加载时间 2s。 - 支持移动端。在 Obsidian 或支持 Wiki 链接的编辑器中[[ ]]内的文本会自动成为可点击的链接带你跳转到相关文档。在 VS Code 中可以安装Markdown Links等插件获得类似体验。预期结果一份结构清晰、自带元数据、且与公司其他知识会议纪要、OKR、技术决策深度互连的 PRD。修改任何被链接的文档都能快速追溯哪些 PRD 会受到影响。测试 2自动化与 AI 集成 —— 用脚本和 AI 处理文档目的验证 Markdown 的“可编程性”实现批量处理和智能摘要。场景 A批量统计所有文档中的任务项创建脚本scripts/count_todos.sh#!/bin/bash # 统计仓库中所有 Markdown 文件里的未完成任务- [ ] echo 搜索所有未完成的任务... grep -r ^- \[ \] . --include*.md | wc -l运行它你可以立刻知道整个公司知识库中还有多少待办事项。场景 B使用 AI 自动生成会议纪要摘要假设你的会议纪要OPERATIONS/Meetings/2024-01-15-Weekly-All-Hands.md内容很长。 你可以编写一个 Python 脚本scripts/summarize_meeting.pyimport os from openai import OpenAI # 配置你的 API 密钥 (请从环境变量读取不要硬编码) client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) def summarize_markdown(filepath): with open(filepath, r, encodingutf-8) as f: content f.read() # 只取会议内容部分跳过 YAML front matter 等 # 这里简化处理实际应用中可能需要更精细的解析 prompt f请将以下会议纪要总结为三个最重要的行动项和决策\n\n{content[:3000]} response client.chat.completions.create( modelgpt-4-turbo-preview, messages[{role: user, content: prompt}], max_tokens500 ) summary response.choices[0].message.content # 将摘要追加到原文件末尾或生成新文件 with open(filepath, a, encodingutf-8) as f: f.write(f\n\n## AI 摘要\n{summary}) print(f已为 {filepath} 生成摘要) if __name__ __main__: summarize_markdown(./OPERATIONS/Meetings/2024-01-15-Weekly-All-Hands.md)运行此脚本即可自动为长会议纪要添加一个清晰的 AI 摘要。验证成功你能通过简单的脚本或 AI 调用对知识库进行批量操作和信息提取极大提升信息处理效率。测试 3版本控制与协作审阅目的验证 Git 在文档协作中的威力。操作步骤同事 Bob 想修改STRATEGY/Go-to-Market.md中的定价策略。Bob 不直接在主分支上修改而是创建一个新分支git checkout -b bob/update-pricing-strategyBob 修改并提交文件。Bob 将分支推送到 GitHub/GitLab并创建一个 Pull Request (PR)。你和 Alice 在 PR 页面上看到 Bob 修改的具体行数并进行评论讨论。经过几轮讨论和修改后你作为负责人将 Bob 的 PR 合并到主分支。预期结果每一次文档的修改都有完整的上下文谁、何时、为什么改、清晰的差异对比以及一个正式的审阅流程。这比在共享网盘中覆盖文件或通过评论链接沟通要严谨得多。6. 接口 API 与批量任务将知识库“服务化”当你的公司知识全部 Markdown 化后它本身就成为了一个结构化的数据库。你可以通过编写简单的“接口”脚本来提供“服务”。示例构建一个简单的“公司信息查询 API”使用 Python 的 FastAPI 框架可以快速创建一个能查询公司文档的本地服务。scripts/company_knowledge_api.py:from fastapi import FastAPI, HTTPException from pathlib import Path import frontmatter import markdown from typing import Optional app FastAPI(titleCompany Knowledge API) KNOWLEDGE_BASE_PATH Path(.) # 假设脚本在仓库根目录运行 app.get(/docs/) def list_docs(): 列出所有 Markdown 文档 md_files list(KNOWLEDGE_BASE_PATH.rglob(*.md)) return {files: [str(f.relative_to(KNOWLEDGE_BASE_PATH)) for f in md_files]} app.get(/docs/{file_path:path}) def get_doc(file_path: str, format: Optional[str] raw): 获取特定文档内容支持 raw原始文本或 html渲染后格式 doc_path KNOWLEDGE_BASE_PATH / file_path if not doc_path.exists() or not doc_path.is_file(): raise HTTPException(status_code404, detailDocument not found) with open(doc_path, r, encodingutf-8) as f: post frontmatter.load(f) content post.content metadata post.metadata if format html: content markdown.markdown(content, extensions[tables, fenced_code]) return { metadata: metadata, content: content if format raw else content, format: format } app.get(/search/) def search_docs(q: str): 在全文档中搜索关键词 results [] for md_file in KNOWLEDGE_BASE_PATH.rglob(*.md): with open(md_file, r, encodingutf-8) as f: if q.lower() in f.read().lower(): results.append(str(md_file.relative_to(KNOWLEDGE_BASE_PATH))) return {query: q, results: results} if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动服务python scripts/company_knowledge_api.py然后你就可以通过curl http://127.0.0.1:8000/docs/PRODUCT/PRD/Epic-1-User-Onboarding.md或浏览器来获取文档的元数据和内容了。这为内部工具集成如聊天机器人、仪表盘提供了可能。批量任务自动化周报生成结合之前的 AI 摘要脚本和 Git 日志可以创建一个自动生成技术团队周报的脚本。scripts/generate_tech_weekly_report.sh#!/bin/bash # 生成技术周报 REPORT_DATE$(date %Y-%m-%d) REPORT_FILEOPERATIONS/Meetings/Tech-Weekly-$REPORT_DATE.md echo # 技术周报 ($REPORT_DATE) $REPORT_FILE echo $REPORT_FILE echo ## 本周代码提交摘要 $REPORT_FILE # 获取过去一周的 Git 提交日志 git log --since1 week ago --oneline --no-merges $REPORT_FILE echo $REPORT_FILE echo ## 新增/更新文档 $REPORT_FILE # 查找过去一周修改过的 Markdown 文件 find . -name *.md -type f -newermt 1 week ago | head -10 $REPORT_FILE echo $REPORT_FILE echo ## 重点问题讨论 (来自 PR 和 Issues) $REPORT_FILE # 这里可以调用 GitHub API 获取相关的 PR 和 Issues 摘要 # curl -s -H Authorization: token YOUR_TOKEN https://api.github.com/repos/your/repo/issues?since$(date -d 1 week ago %Y-%m-%dT%H:%M:%SZ) | jq .[] | .title | head -5 $REPORT_FILE echo - [链接到具体 PR 或 Issue] $REPORT_FILE echo 周报草稿已生成: $REPORT_FILE # 接下来可以调用 AI 脚本对这份草稿进行润色和总结 # python scripts/summarize_with_ai.py $REPORT_FILE将这个脚本加入定时任务如 crontab即可实现周报的自动生成。7. 资源占用与性能观察这里的“性能”不是指 GPU 显存而是指工作流的效率和系统的可扩展性。存储占用极低。纯文本的 Markdown 文件体积可以忽略不计。主要的存储开销来自assets/目录下的图片等二进制文件。一个包含数年文档的知识库可能也只有几十到几百 MB。“启动”速度极快。打开编辑器VS Code/Obsidian并加载项目文件夹几乎是瞬间完成的。搜索全文内容也远比打开多个 SaaS 平台并等待页面加载要快。协作性能依赖于 Git 工作流的熟练度。对于小型团队基于分支和 PR 的协作模式非常高效。对于大型团队或频繁冲突的文档可能需要更精细的分工或借助 Git 的合并工具如meld,kdiff3。搜索效率本地全文搜索如 VS Code 的CtrlShiftF或grep是毫秒级的。这比在 Confluence 或 Notion 中等待搜索接口返回结果要快得多。自动化扩展性极佳。因为文件系统是标准的任何支持读写文本文件的编程语言都可以与之交互自动化脚本的编写几乎没有限制。性能瓶颈可能出现在单个 Markdown 文件过大例如超过 1 万行会影响编辑器的响应速度。解决方案是合理拆分文档。图片等资源文件过多导致 Git 仓库克隆变慢。解决方案是使用 Git LFS 或外部资源链接。团队成员 Git 操作不熟练导致合并冲突频发。解决方案是制定简单的协作规范并进行培训。8. 常见问题与排查方法在实践“Markdown 公司”理念时你会遇到一些典型问题。问题现象可能原因排查方式解决方案编辑器中[[链接]]不生效编辑器未安装相关插件或未启用 Wiki 链接功能。检查编辑器设置或插件市场。在 VS Code 中安装Markdown Links或Foam插件在 Obsidian 中确保“内部链接”功能已开启。Git 合并冲突多人同时修改了同一文件的同一区域。运行git status查看冲突文件用编辑器打开冲突文件查看,,标记。1. 沟通协商手动解决冲突。2. 使用图形化合并工具。3. 建立规范细粒度文件避免多人编辑同一小节。图片无法显示图片路径错误或图片未提交到 Git。检查 Markdown 中的图片路径是相对路径还是绝对路径。使用git status查看图片文件是否已跟踪。使用相对路径如./assets/image.png。确保图片文件已git add并提交。对于大量图片考虑使用图床。自动化脚本执行失败脚本没有执行权限或依赖未安装。在终端运行脚本查看具体报错信息。1. 添加执行权限chmod x script.sh。2. 安装所需依赖如 Python 包。3. 检查文件路径是否正确脚本可能在仓库外运行。感觉没有 SaaS 工具方便初期搭建结构和适应新工作流需要成本。反思是哪个具体环节不便是写作、分享、搜索还是协作1.写作坚持使用Markdown 语法很快能熟练。2.分享将仓库设为私有分享 Git 链接或渲染后的 HTML。3.搜索体验本地全文搜索的速度优势。4.协作推行清晰的 Git 分支/Pull Request 流程。历史版本追溯麻烦不熟悉 Git 命令。尝试使用 Git 图形化客户端。使用git log --oneline --graph查看历史或直接使用 GitHub/GitLab 的网页界面查看文件历史非常直观。AI 处理长文档效果差超过了 AI 模型的上下文长度限制。检查文档长度和 API 调用的 token 数。1. 将长文档拆分成逻辑章节。2. 在调用 AI 前先用脚本提取关键部分。3. 使用支持长上下文的模型如 Claude。9. 最佳实践与使用建议要让“Markdown 公司”的理念发挥最大效用需要遵循一些最佳实践。始于简单保持简洁不要一开始就追求完美的复杂结构。从一个README.md和一个ideas/文件夹开始。让结构随着项目自然生长。约定优于配置建立团队内部的 Markdown 写作规范。文件名使用短横线分隔的英文project-brief.md避免空格和特殊字符。Front Matter统一使用 YAML 格式在文件头记录元数据如title,status,author,date。标题层级从# H1开始顺序嵌套不要跳级。链接方式优先使用相对路径的[[内部链接]]Obsidian风格或[文本](相对路径)。原子化文档一个文档只讲清楚一件事。避免创建包罗万象的“巨无霸”文档。这有利于链接、复用和单独维护。将二进制资产外置图片、视频、大型附件不要直接塞进 Git 仓库。使用相对路径链接到assets/目录并使用 Git LFS 管理或上传到专门的图床/文件存储服务。提交信息即日志养成写有意义的 Git 提交信息的习惯。git commit -m 更新了定价策略远不如git commit -m docs(strategy): 根据Q1市场数据更新基础版定价为$9.99 (refs #123)有用。后者清晰地说明了修改范围、内容和关联的问题。自动化一切重复劳动凡是需要手动操作超过三次的事情就考虑写个脚本。无论是生成报告、同步内容到其他平台还是检查文档中的死链。定期“园艺”像打理花园一样打理你的知识库。定期检查并修复死链合并过于琐碎的文档归档过时的内容确保结构清晰。安全与备份私有仓库商业敏感信息务必放在私有 Git 仓库中。多地点备份除了 Git 远程仓库定期将整个知识库打包备份到其他位置。敏感信息绝对不要在 Markdown 文件中硬编码密码、API 密钥。使用环境变量或专门的秘密管理工具。10. 总结与下一步Garry Tan 的“未来整个创业公司就是 Markdown 文件”观点本质上是对“知识即资产且资产应可编程”这一理念的极致表达。它不是一个现成的产品而是一套需要你亲手搭建并不断优化的元系统。这套方法的真正威力不在于 Markdown 语法本身而在于它如何将创作、版本管理、协作、自动化通过最简单的文本格式和最强大的工具链Git, CLI, AI无缝衔接起来。它迫使你思考信息的本质结构并赋予你用代码操纵一切知识的能力。对于个人或团队而言最直接的下一步行动是选择一个当前最让你头疼的知识管理或协作问题尝试用纯 Markdown Git 的方式来解决它。比如将你的个人学习笔记从多个地方迁移到一个 Obsidian 库中。为你的下一个 Side Project 在 GitHub 上创建一个仓库用 Markdown 写产品规划、开发日志和发布说明。在团队的下一次项目复盘会上不使用 PPT而是共同编辑一份结构化的retrospective.md文件并提交 PR 进行讨论。开始时可能会觉得繁琐但一旦你习惯了这种“一切皆文本一切皆可追溯一切皆可自动化”的工作流就很难再回到那些封闭、笨重、数据难以导出的传统工具中。这不仅是工具的升级更是工作思维的进化。 Markdown+Git+AI：构建可编程知识库的创业公司协作新范式
这次我们来看一个很有意思的观点Garry Tan 提出的“未来整个创业公司就是 Markdown 文件”。这不是一个具体的软件或模型而是一个关于软件开发、团队协作和知识管理未来形态的前沿理念。对于开发者、产品经理和创业者来说理解这个观点意味着理解下一代工具如何重塑我们的工作流。简单来说这个观点认为一个公司的核心资产——产品需求、设计文档、代码、运营策略、甚至财务模型——都可以被结构化为 Markdown 文件并通过现代工具链如 Git、AI 代理、自动化工作流进行管理、协作和演化。它解决的核心问题是信息孤岛、工具割裂和协作低效。如果你厌倦了在 Confluence、Notion、Figma、Jira、GitHub 和一堆 Excel 表格之间来回切换那么这个理念值得你深入了解。本文不会介绍一个可以“一键启动”的软件但会深入拆解这个理念背后的技术栈、实践方法和工具链。我们将探讨Markdown 为何能成为“单一事实来源”如何用现有的工具如 Obsidian、VS Code、Git构建一个以 Markdown 为中心的创业公司知识库以及 AI如 Claude、GPT如何作为“员工”直接读取和操作这些 Markdown 文件实现自动化。无论你是想优化个人工作流还是为团队寻找更高效的协作范式这篇文章都将提供一套可落地的思路和具体操作指南。1. 核心能力速览Markdown 作为公司核心的可行性分析首先我们需要明确“创业公司即 Markdown 文件”不是一个已经打包好的产品而是一个架构理念和最佳实践的集合。它的“核心能力”体现在对信息处理方式的根本性变革上。能力项说明与解读核心理念将公司所有非代码类知识资产想法、规划、文档、数据以纯文本 Markdown 格式存储实现人机皆可读、可版本控制、可自动化处理。技术门槛低。主要依赖通用文本编辑器、Git 和命令行工具无需特定商业软件许可。核心工具链编辑器VS Code, Obsidian版本控制GitCLI 工具AI 接口OpenAI, Anthropic。“启动”方式从建立一个 Git 仓库开始用 Markdown 撰写第一份产品构想文档。“接口”能力极强。Markdown 是纯文本可通过脚本、AI API 进行批量读取、分析、转换和生成。“批量任务”支持原生支持。可通过 Shell/Python 脚本对整个目录的 Markdown 文件进行批量操作如统计、搜索、格式转换、内容同步。适合场景初创团队特别是技术背景强的、远程异步协作、个人知识管理、需要高度自动化和可追溯性的项目。这个理念的吸引力在于其极简和强大的二元性格式简单到用记事本就能写但生态强大到可以连接整个现代开发与AI工具链。2. 适用场景与使用边界谁适合采用这种模式技术驱动的初创公司工程师文化浓厚习惯使用 Git追求效率和自动化。小型远程团队需要清晰的异步文档协作减少会议沟通。独立开发者和创作者希望统一管理项目文档、日志、内容草稿和待办事项。追求“可编程知识库”的团队希望用代码的方式管理文档例如自动生成周报、同步数据到不同平台。它能解决什么问题信息碎片化设计稿在 Figma需求在 Jira会议纪要在 Google Docs最终谁是最新版本协作上下文丢失新成员入职需要翻看无数个链接和历史聊天记录才能了解项目全貌。知识资产无法复用过去的项目复盘、市场分析无法被轻易搜索和提取到新项目中。流程自动化困难因为数据被锁在封闭的 SaaS 工具里难以与内部工具链集成。它的边界与挑战非技术成员上手成本对于不熟悉 Markdown 语法、Git 基本操作的成员需要一定的学习和适应期。富媒体内容处理图片、视频等二进制文件仍需外部存储Markdown 中仅保存链接。但这恰好符合“关注点分离”的原则。复杂的表单和数据库场景对于需要强结构化、实时协作编辑的数据如复杂的财务表格专门的工具可能更合适。但 Markdown 表格和 YAML Front Matter 可以解决大部分轻度结构化数据需求。企业级权限与审计原生 Git 的权限管理不如专业企业级文档平台精细需要搭配 Git 托管平台如 GitHub, GitLab的团队功能。重要提醒此模式强调信息的开放性和可操作性但同样需要注意数据安全。涉及敏感信息如商业机密、个人隐私的文档必须通过私有仓库、加密工具或严格的访问控制来管理。3. 环境准备与前置条件构建一个“Markdown 公司”不需要高性能 GPU但对工具链的熟悉程度有要求。以下是你的“数字办公环境”清单核心编辑器任选其一VS Code微软出品插件生态极其丰富内置 Git 管理适合开发者。必装插件Markdown All in One,Markdown Preview Enhanced,Paste Image方便插入本地图片。Obsidian以“双向链接”和“知识图谱”著称所有数据以本地 Markdown 文件存储非常适合构建相互关联的知识库。社区插件强大。Vim/Neovim 或 Emacs适合终端爱好者通过配置可以达到极高的编辑效率。版本控制系统Git必备技能。不仅是代码文档的每一次修改都应该提交并附上有意义的注释。Git 图形化客户端可选如 GitHub Desktop, Sourcetree方便不习惯命令行的成员进行提交、拉取和查看历史。文件同步与备份Git 托管平台GitHub, GitLab, Gitee。用于远程备份、团队协作和 Pull Request 审阅流程。同步盘可选如 iCloud Drive, Dropbox, Syncthing。用于在多设备间同步 Obsidian 库等。命令行环境Bash/Zsh/Fish在 Unix-like 系统macOS, Linux或 WSLWindows上命令行是执行批量操作和自动化脚本的关键。核心命令行工具find,grep,sed,awk。用于快速搜索和转换文本。AI 助手接入可选但推荐OpenAI API 或 Anthropic Claude API用于让 AI 理解、总结、改写或基于你的 Markdown 知识库生成内容。相关脚本工具如llm(Simon Willison 的命令行工具)可以方便地在终端与 AI 交互。4. 安装部署与启动方式建立你的第一个“公司仓库”这里没有docker-compose up你的“启动”命令是git init。第一步规划仓库结构在开始写任何内容之前先设计一个清晰的文件目录结构。这是一个模拟的创业公司仓库示例your-startup-repo/ ├── README.md # 公司/项目总览 ├── VISION.md # 愿景与使命 ├── STRATEGY/ │ ├── Product-Roadmap.md # 产品路线图 │ ├── Go-to-Market.md # 市场进入策略 │ └── Competitive-Analysis.md # 竞争分析 ├── PRODUCT/ │ ├── PRD/ # 产品需求文档 │ │ ├── Epic-1-Feature-A.md │ │ └── Epic-2-Feature-B.md │ ├── Design/ # 设计文档与决策记录 │ │ └── Design-System-Decisions.md │ └── Specs/ # 技术规格 │ └── API-Spec-v1.md ├── ENGINEERING/ │ ├── ADRs/ # 架构决策记录 (Architecture Decision Records) │ │ └── 2024-01-01-use-nextjs.md │ └── Runbooks/ # 运维手册 │ └── Deployment-Procedure.md ├── OPERATIONS/ │ ├── OKRs/ # 目标与关键成果 │ │ └── Q1-2024.md │ ├── Processes/ # 工作流程 │ │ └── How-We-Hire.md │ └── Meetings/ # 会议纪要 │ └── 2024-01-15-Weekly-All-Hands.md ├── MARKETING/ │ └── Content-Calendar.md ├── assets/ # 图片等静态资源 │ └── product-screenshot-v1.png └── scripts/ # 自动化脚本 ├── sync_to_notion.py # 示例将 Markdown 同步到 Notion └── generate_weekly_report.sh # 示例生成周报第二步初始化仓库并提交# 1. 创建目录并进入 mkdir my-startup-wiki cd my-startup-wiki # 2. 初始化 Git 仓库 git init # 3. 创建上述目录结构 (可以使用 mkdir -p 命令批量创建) mkdir -p STRATEGY PRODUCT/PRD PRODUCT/Design PRODUCT/Specs ENGINEERING/ADRs ENGINEERING/Runbooks OPERATIONS/OKRs OPERATIONS/Processes OPERATIONS/Meetings MARKETING assets scripts # 4. 创建第一个核心文件README.md echo # My Startup README.md echo ## Vision README.md echo To build the future with Markdown. README.md # 5. 进行首次提交 git add . git commit -m Initial commit: Repository structure and README第三步连接远程仓库以 GitHub 为例在 GitHub 上创建一个新的空仓库不要初始化 README。按照 GitHub 的提示将本地仓库与远程仓库关联。git remote add origin https://github.com/yourusername/your-startup-repo.git git branch -M main git push -u origin main至此你的“公司”已经“启动”了。所有后续的思考、决策和创作都将在这个结构化的文本仓库中发生。5. 功能测试与效果验证让 Markdown 真正工作起来仅仅存储文本是不够的我们需要验证这套体系如何解决实际问题。下面通过几个具体场景来测试。测试 1高效创作与链接 —— 撰写一份产品需求文档PRD目的验证用 Markdown 写复杂文档的可行性并利用双向链接建立文档网络。操作步骤在PRODUCT/PRD/目录下创建Epic-1-User-Onboarding.md。使用 Markdown 语法撰写并融入一些高级实践--- title: 用户引导流程优化 (Epic #1) status: In Progress author: alice created: 2024-01-15 related: - ../Design/Onboarding-UI-Sketch.md - ../../STRATEGY/Go-to-Market.md#target-users --- # 用户引导流程优化 (Epic #1) ## 背景与问题 目前的新用户激活率仅为 30%。根据 [[../../OPERATIONS/Meetings/2024-01-10-User-Research-Summary.md]] 中的访谈问题主要出在... ## 目标 - **主要目标**将新用户激活率提升至 50%。 - **成功指标**见 [[../../OPERATIONS/OKRs/Q1-2024.md#objective-2]]。 ## 用户故事 1. 作为一个新用户我希望...以便于... 2. [故事2]... ## 功能需求 ### F1: 个性化欢迎教程 - **描述**根据用户注册来源显示定制化的第一步教程。 - **设计参考**  - **技术关联**此功能依赖于 [[../../ENGINEERING/ADRs/2024-01-01-use-nextjs.md]] 中决定的前端框架。 ## 非功能需求 - 页面加载时间 2s。 - 支持移动端。在 Obsidian 或支持 Wiki 链接的编辑器中[[ ]]内的文本会自动成为可点击的链接带你跳转到相关文档。在 VS Code 中可以安装Markdown Links等插件获得类似体验。预期结果一份结构清晰、自带元数据、且与公司其他知识会议纪要、OKR、技术决策深度互连的 PRD。修改任何被链接的文档都能快速追溯哪些 PRD 会受到影响。测试 2自动化与 AI 集成 —— 用脚本和 AI 处理文档目的验证 Markdown 的“可编程性”实现批量处理和智能摘要。场景 A批量统计所有文档中的任务项创建脚本scripts/count_todos.sh#!/bin/bash # 统计仓库中所有 Markdown 文件里的未完成任务- [ ] echo 搜索所有未完成的任务... grep -r ^- \[ \] . --include*.md | wc -l运行它你可以立刻知道整个公司知识库中还有多少待办事项。场景 B使用 AI 自动生成会议纪要摘要假设你的会议纪要OPERATIONS/Meetings/2024-01-15-Weekly-All-Hands.md内容很长。 你可以编写一个 Python 脚本scripts/summarize_meeting.pyimport os from openai import OpenAI # 配置你的 API 密钥 (请从环境变量读取不要硬编码) client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) def summarize_markdown(filepath): with open(filepath, r, encodingutf-8) as f: content f.read() # 只取会议内容部分跳过 YAML front matter 等 # 这里简化处理实际应用中可能需要更精细的解析 prompt f请将以下会议纪要总结为三个最重要的行动项和决策\n\n{content[:3000]} response client.chat.completions.create( modelgpt-4-turbo-preview, messages[{role: user, content: prompt}], max_tokens500 ) summary response.choices[0].message.content # 将摘要追加到原文件末尾或生成新文件 with open(filepath, a, encodingutf-8) as f: f.write(f\n\n## AI 摘要\n{summary}) print(f已为 {filepath} 生成摘要) if __name__ __main__: summarize_markdown(./OPERATIONS/Meetings/2024-01-15-Weekly-All-Hands.md)运行此脚本即可自动为长会议纪要添加一个清晰的 AI 摘要。验证成功你能通过简单的脚本或 AI 调用对知识库进行批量操作和信息提取极大提升信息处理效率。测试 3版本控制与协作审阅目的验证 Git 在文档协作中的威力。操作步骤同事 Bob 想修改STRATEGY/Go-to-Market.md中的定价策略。Bob 不直接在主分支上修改而是创建一个新分支git checkout -b bob/update-pricing-strategyBob 修改并提交文件。Bob 将分支推送到 GitHub/GitLab并创建一个 Pull Request (PR)。你和 Alice 在 PR 页面上看到 Bob 修改的具体行数并进行评论讨论。经过几轮讨论和修改后你作为负责人将 Bob 的 PR 合并到主分支。预期结果每一次文档的修改都有完整的上下文谁、何时、为什么改、清晰的差异对比以及一个正式的审阅流程。这比在共享网盘中覆盖文件或通过评论链接沟通要严谨得多。6. 接口 API 与批量任务将知识库“服务化”当你的公司知识全部 Markdown 化后它本身就成为了一个结构化的数据库。你可以通过编写简单的“接口”脚本来提供“服务”。示例构建一个简单的“公司信息查询 API”使用 Python 的 FastAPI 框架可以快速创建一个能查询公司文档的本地服务。scripts/company_knowledge_api.py:from fastapi import FastAPI, HTTPException from pathlib import Path import frontmatter import markdown from typing import Optional app FastAPI(titleCompany Knowledge API) KNOWLEDGE_BASE_PATH Path(.) # 假设脚本在仓库根目录运行 app.get(/docs/) def list_docs(): 列出所有 Markdown 文档 md_files list(KNOWLEDGE_BASE_PATH.rglob(*.md)) return {files: [str(f.relative_to(KNOWLEDGE_BASE_PATH)) for f in md_files]} app.get(/docs/{file_path:path}) def get_doc(file_path: str, format: Optional[str] raw): 获取特定文档内容支持 raw原始文本或 html渲染后格式 doc_path KNOWLEDGE_BASE_PATH / file_path if not doc_path.exists() or not doc_path.is_file(): raise HTTPException(status_code404, detailDocument not found) with open(doc_path, r, encodingutf-8) as f: post frontmatter.load(f) content post.content metadata post.metadata if format html: content markdown.markdown(content, extensions[tables, fenced_code]) return { metadata: metadata, content: content if format raw else content, format: format } app.get(/search/) def search_docs(q: str): 在全文档中搜索关键词 results [] for md_file in KNOWLEDGE_BASE_PATH.rglob(*.md): with open(md_file, r, encodingutf-8) as f: if q.lower() in f.read().lower(): results.append(str(md_file.relative_to(KNOWLEDGE_BASE_PATH))) return {query: q, results: results} if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动服务python scripts/company_knowledge_api.py然后你就可以通过curl http://127.0.0.1:8000/docs/PRODUCT/PRD/Epic-1-User-Onboarding.md或浏览器来获取文档的元数据和内容了。这为内部工具集成如聊天机器人、仪表盘提供了可能。批量任务自动化周报生成结合之前的 AI 摘要脚本和 Git 日志可以创建一个自动生成技术团队周报的脚本。scripts/generate_tech_weekly_report.sh#!/bin/bash # 生成技术周报 REPORT_DATE$(date %Y-%m-%d) REPORT_FILEOPERATIONS/Meetings/Tech-Weekly-$REPORT_DATE.md echo # 技术周报 ($REPORT_DATE) $REPORT_FILE echo $REPORT_FILE echo ## 本周代码提交摘要 $REPORT_FILE # 获取过去一周的 Git 提交日志 git log --since1 week ago --oneline --no-merges $REPORT_FILE echo $REPORT_FILE echo ## 新增/更新文档 $REPORT_FILE # 查找过去一周修改过的 Markdown 文件 find . -name *.md -type f -newermt 1 week ago | head -10 $REPORT_FILE echo $REPORT_FILE echo ## 重点问题讨论 (来自 PR 和 Issues) $REPORT_FILE # 这里可以调用 GitHub API 获取相关的 PR 和 Issues 摘要 # curl -s -H Authorization: token YOUR_TOKEN https://api.github.com/repos/your/repo/issues?since$(date -d 1 week ago %Y-%m-%dT%H:%M:%SZ) | jq .[] | .title | head -5 $REPORT_FILE echo - [链接到具体 PR 或 Issue] $REPORT_FILE echo 周报草稿已生成: $REPORT_FILE # 接下来可以调用 AI 脚本对这份草稿进行润色和总结 # python scripts/summarize_with_ai.py $REPORT_FILE将这个脚本加入定时任务如 crontab即可实现周报的自动生成。7. 资源占用与性能观察这里的“性能”不是指 GPU 显存而是指工作流的效率和系统的可扩展性。存储占用极低。纯文本的 Markdown 文件体积可以忽略不计。主要的存储开销来自assets/目录下的图片等二进制文件。一个包含数年文档的知识库可能也只有几十到几百 MB。“启动”速度极快。打开编辑器VS Code/Obsidian并加载项目文件夹几乎是瞬间完成的。搜索全文内容也远比打开多个 SaaS 平台并等待页面加载要快。协作性能依赖于 Git 工作流的熟练度。对于小型团队基于分支和 PR 的协作模式非常高效。对于大型团队或频繁冲突的文档可能需要更精细的分工或借助 Git 的合并工具如meld,kdiff3。搜索效率本地全文搜索如 VS Code 的CtrlShiftF或grep是毫秒级的。这比在 Confluence 或 Notion 中等待搜索接口返回结果要快得多。自动化扩展性极佳。因为文件系统是标准的任何支持读写文本文件的编程语言都可以与之交互自动化脚本的编写几乎没有限制。性能瓶颈可能出现在单个 Markdown 文件过大例如超过 1 万行会影响编辑器的响应速度。解决方案是合理拆分文档。图片等资源文件过多导致 Git 仓库克隆变慢。解决方案是使用 Git LFS 或外部资源链接。团队成员 Git 操作不熟练导致合并冲突频发。解决方案是制定简单的协作规范并进行培训。8. 常见问题与排查方法在实践“Markdown 公司”理念时你会遇到一些典型问题。问题现象可能原因排查方式解决方案编辑器中[[链接]]不生效编辑器未安装相关插件或未启用 Wiki 链接功能。检查编辑器设置或插件市场。在 VS Code 中安装Markdown Links或Foam插件在 Obsidian 中确保“内部链接”功能已开启。Git 合并冲突多人同时修改了同一文件的同一区域。运行git status查看冲突文件用编辑器打开冲突文件查看,,标记。1. 沟通协商手动解决冲突。2. 使用图形化合并工具。3. 建立规范细粒度文件避免多人编辑同一小节。图片无法显示图片路径错误或图片未提交到 Git。检查 Markdown 中的图片路径是相对路径还是绝对路径。使用git status查看图片文件是否已跟踪。使用相对路径如./assets/image.png。确保图片文件已git add并提交。对于大量图片考虑使用图床。自动化脚本执行失败脚本没有执行权限或依赖未安装。在终端运行脚本查看具体报错信息。1. 添加执行权限chmod x script.sh。2. 安装所需依赖如 Python 包。3. 检查文件路径是否正确脚本可能在仓库外运行。感觉没有 SaaS 工具方便初期搭建结构和适应新工作流需要成本。反思是哪个具体环节不便是写作、分享、搜索还是协作1.写作坚持使用Markdown 语法很快能熟练。2.分享将仓库设为私有分享 Git 链接或渲染后的 HTML。3.搜索体验本地全文搜索的速度优势。4.协作推行清晰的 Git 分支/Pull Request 流程。历史版本追溯麻烦不熟悉 Git 命令。尝试使用 Git 图形化客户端。使用git log --oneline --graph查看历史或直接使用 GitHub/GitLab 的网页界面查看文件历史非常直观。AI 处理长文档效果差超过了 AI 模型的上下文长度限制。检查文档长度和 API 调用的 token 数。1. 将长文档拆分成逻辑章节。2. 在调用 AI 前先用脚本提取关键部分。3. 使用支持长上下文的模型如 Claude。9. 最佳实践与使用建议要让“Markdown 公司”的理念发挥最大效用需要遵循一些最佳实践。始于简单保持简洁不要一开始就追求完美的复杂结构。从一个README.md和一个ideas/文件夹开始。让结构随着项目自然生长。约定优于配置建立团队内部的 Markdown 写作规范。文件名使用短横线分隔的英文project-brief.md避免空格和特殊字符。Front Matter统一使用 YAML 格式在文件头记录元数据如title,status,author,date。标题层级从# H1开始顺序嵌套不要跳级。链接方式优先使用相对路径的[[内部链接]]Obsidian风格或[文本](相对路径)。原子化文档一个文档只讲清楚一件事。避免创建包罗万象的“巨无霸”文档。这有利于链接、复用和单独维护。将二进制资产外置图片、视频、大型附件不要直接塞进 Git 仓库。使用相对路径链接到assets/目录并使用 Git LFS 管理或上传到专门的图床/文件存储服务。提交信息即日志养成写有意义的 Git 提交信息的习惯。git commit -m 更新了定价策略远不如git commit -m docs(strategy): 根据Q1市场数据更新基础版定价为$9.99 (refs #123)有用。后者清晰地说明了修改范围、内容和关联的问题。自动化一切重复劳动凡是需要手动操作超过三次的事情就考虑写个脚本。无论是生成报告、同步内容到其他平台还是检查文档中的死链。定期“园艺”像打理花园一样打理你的知识库。定期检查并修复死链合并过于琐碎的文档归档过时的内容确保结构清晰。安全与备份私有仓库商业敏感信息务必放在私有 Git 仓库中。多地点备份除了 Git 远程仓库定期将整个知识库打包备份到其他位置。敏感信息绝对不要在 Markdown 文件中硬编码密码、API 密钥。使用环境变量或专门的秘密管理工具。10. 总结与下一步Garry Tan 的“未来整个创业公司就是 Markdown 文件”观点本质上是对“知识即资产且资产应可编程”这一理念的极致表达。它不是一个现成的产品而是一套需要你亲手搭建并不断优化的元系统。这套方法的真正威力不在于 Markdown 语法本身而在于它如何将创作、版本管理、协作、自动化通过最简单的文本格式和最强大的工具链Git, CLI, AI无缝衔接起来。它迫使你思考信息的本质结构并赋予你用代码操纵一切知识的能力。对于个人或团队而言最直接的下一步行动是选择一个当前最让你头疼的知识管理或协作问题尝试用纯 Markdown Git 的方式来解决它。比如将你的个人学习笔记从多个地方迁移到一个 Obsidian 库中。为你的下一个 Side Project 在 GitHub 上创建一个仓库用 Markdown 写产品规划、开发日志和发布说明。在团队的下一次项目复盘会上不使用 PPT而是共同编辑一份结构化的retrospective.md文件并提交 PR 进行讨论。开始时可能会觉得繁琐但一旦你习惯了这种“一切皆文本一切皆可追溯一切皆可自动化”的工作流就很难再回到那些封闭、笨重、数据难以导出的传统工具中。这不仅是工具的升级更是工作思维的进化。