企业 AI 情报、Blog 与资源公开预览所有状态以页面说明为准

Vaysen AI
联系会员状态
菜单

Published article

用 Markdown 建立可复用的 AI 工作项目

把项目背景、工作规则、关键决定和待确认问题整理为可迁移、可复核的工作底稿，让人与 AI 可以在同一套事实和边界上继续协作。

Vaysen约 5 分钟阅读迁移稿 02 · 已复核公开

很多人使用 AI 时，最费力的不是第一次给出指令，而是每次都要重新解释背景：公司做什么、这次项目要解决什么、哪些信息可信、哪些动作不能做、上次已经决定了什么。

解决这个问题，不一定要先购买复杂的知识库系统。一个结构清楚的项目目录，加上几份持续维护的 Markdown 文档，就能成为人与 AI 共同使用的工作底稿。

Markdown 在这里扮演什么角色

Markdown 是一种轻量文本格式。它可以表示标题、列表、链接、表格和代码，又仍然保持纯文本，方便用编辑器阅读、用 Git 记录变化、用不同工具迁移。

真正重要的不是扩展名，而是把原本散落在聊天记录、个人记忆和临时文件里的信息，整理成可检查的项目上下文。

一个好的项目上下文至少回答五个问题：

  1. 这个项目为什么存在？
  2. 当前目标和范围是什么？
  3. 哪些事实已经确认，来源在哪里？
  4. 执行时必须遵守哪些规则和边界？
  5. 下一步是什么，还有哪些问题没有答案？

一套够用的最小目录

你可以从下面的结构开始，再随业务复杂度扩展：

my-project/
├─ 00-START-HERE.md
├─ AGENTS.md
├─ DECISIONS.md
├─ Open-Questions.md
├─ CHANGELOG.md
├─ docs/
├─ assets/
└─ private/

00-START-HERE.md：接手入口

这份文件让新成员或新的 AI 会话快速理解项目。它只保留当前仍有效的信息：项目定位、当前阶段、关键目录、已确认事项和接下来要做的工作。

它不是完整档案，而是一张导航图。内容过长时，应把细节放进对应文档，只在这里留下链接。

AGENTS.md：工作规则

这里记录执行任务时必须遵守的约束，例如：

  • 哪份文档是业务事实来源；
  • 哪些文件可以修改，哪些只能读取；
  • 缺失信息应该记录在哪里；
  • 哪些数据不能进入公开仓库；
  • 完成任务后需要更新哪些记录和测试。

规则应该具体、可验证。像“注意安全”这样的句子无法指导行动；“客户数据、密钥和生产配置不得进入公开仓库”才是可以执行的边界。

DECISIONS.md：只记录已经确认的决定

讨论、建议和正式决定要分开。DECISIONS.md 记录已经确认的方向、日期、理由和影响范围。这样可以避免下一次协作时把旧讨论重新当成开放问题，也能看见某个选择为什么存在。

如果决定后来失效，不要悄悄覆盖。保留变更记录，并说明新决定替代了什么。

Open-Questions.md：承认不知道

项目最危险的情况之一，是把缺失信息用听起来合理的答案补上。尚未确认的价格、客户授权、产品能力、平台规则和数据口径，都应该进入问题清单，并写明负责人或验证方式。

把“不知道”显式化，会让项目更可靠，而不是显得不专业。

CHANGELOG.md：记录实际发生的变化

CHANGELOG 不需要复制每一行代码。它应该让人快速知道：这次完成了什么、影响哪些范围、是否有迁移或兼容注意事项、还剩下什么。

第一次建立项目时怎么写

不要一开始就追求几十份模板。可以先完成三个动作。

第一步：写清目标和非目标

在 00-START-HERE.md 中用几句话说明项目目标，并同时写出当前不做什么。

例如，一个“外贸询盘处理”项目的目标可以是：统一询盘字段、整理产品匹配依据、生成需要人工确认的回复草稿。非目标则可以包括：不自动发送邮件、不保存不必要的个人数据、不替代销售人员做最终报价承诺。

第二步：列出事实、来源和待确认项

把已经确认的产品资料、流程说明和权限边界放进 docs/，同时记录来源。没有证据的推测进入 Open-Questions.md。

这样做以后，AI 的任务就从“根据模糊描述猜答案”变成“在给定事实和边界内完成具体工作”。

第三步：完成一次小任务并回写

选择一个结果容易检查的小任务，例如整理一份字段表、生成一个待审核的邮件框架或比较两个流程版本。完成后更新 CHANGELOG，并把新确认的规则写回相应文档。

项目化的价值来自持续回写。只创建目录、不维护内容，最终仍会变成另一堆失效文件。

用 Git 保留变化，但不要把所有东西都提交

Git 可以记录谁在什么时候修改了什么，也能在错误发生时比较版本。但在提交前，需要先划定公开与私密边界。

通常不应进入公开仓库的内容包括：

  • API Key、密码、Cookie 和登录凭据；
  • 客户名单、联系人、报价和合同；
  • 生产数据库、备份和服务器配置；
  • 未获得授权的客户案例、聊天记录和内部素材；
  • 可以推导个人身份或企业敏感情况的数据。

把私密目录加入忽略规则只是第一道防线。还要在提交前检查变更，并为生产密钥使用专门的密钥管理方式。

让文档保持有用的四条规则

  1. 事实和建议分开：事实写来源，建议写依据和假设。
  2. 状态必须明确：草稿、待复核、已批准和已发布不能混用。
  3. 入口保持简短：主索引负责导航，细节进入专题文档。
  4. 工作结束要回写：把结果、决定、反例和下一步留在项目里。

AI 可以参与，但终审责任仍在人

AI 适合帮助整理材料、发现冲突、生成初稿、补充检查项和执行重复步骤。涉及事实发布、客户承诺、付款、权限、删除、对外消息和生产变更时，仍需要明确的人类审核。

文档不是为了让 AI 不受限制地行动，而是为了同时提供上下文和边界。

今天就可以开始

新建一个项目目录，先写 00-START-HERE.md、AGENTS.md 和 Open-Questions.md。选择一个真实、可检查的小任务跑完，再把新事实和结果写回来。

当下一次换设备、换工具或换协作者时，如果对方能够从这些文件继续工作，而不需要你重新讲一遍全部背景，这套项目底稿就已经开始产生价值。