AI Collaboration Operating System ✨

English README

一个仍在早期、但已经可以拿来试试的轻量 AI 协作 skill 实验。

它不是一个成型产品，也不是一套已经定型的工程方法论。现在的它更像一个起点：我们希望用一个可复用、可迁移、足够克制的 skill，帮助小项目、练手项目、初创团队、黑客松作品和早期产品，更快建立 AI 协作的基本秩序。

🧭 这是什么

这个仓库的核心入口仍然是一个轻量 skill，但它已经从最初的单文件形态，长出了一点点辅助材料：

skills/
  project-collaboration-operating-system/
    SKILL.md
    references/
    templates/

这个 skill 试图帮助项目回答一类早期协作问题：AI 应该先读什么，哪些文档更权威，什么时候不该扩大工程范围，做完一件事需要怎样证明，以及当人和 AI 的协作偏航时，如何把经验沉淀成下一次更好的行动。

更具体的规则和使用方式都在 SKILL.md 里。references/ 和 templates/ 只是放一些案例、压力检查和可复制调用方式。README 不想把它们再讲一遍，只想说明这个项目为什么存在，以及我们希望它怎样继续长大。

🚀 快速开始

这个 skill 既可以帮一个只有零散想法的新项目建立最小协作起点，也可以检查一个已有项目的人与 AI 协作方式。你不需要先理解它的四种工作模式，只需要从自己现在所处的位置开始。

安装

如果本地已经安装了 Node.js，可以在终端运行：

npx skills add yhala2414/ai-collaboration-operating-system --skill project-collaboration-operating-system

这个命令会通过通用的 skills CLI 从 GitHub 读取仓库，识别你正在使用的 AI agent，并安装其中的 skill；本项目本身没有发布 npm 包。

也可以直接下载仓库，或者使用 Git 克隆：

git clone https://github.com/yhala2414/ai-collaboration-operating-system.git

然后把仓库中的下面这个完整目录复制到 AI 工具的 skills 目录：

skills/project-collaboration-operating-system/

手动复制时，目标目录里应当保留 SKILL.md、references/ 和 templates/。不同工具的 skills 目录可能不同，请以你所使用工具的说明为准。安装完成后，重新打开 AI 工具或开始一个新会话，然后让 agent 使用 project-collaboration-operating-system。

如果你的工具暂时不支持 skills，也可以直接阅读 SKILL.md，把它当作一份轻量的协作体系检查清单。

如果你正从零开始

“从零”不一定是什么都没有。你可能已经有一些想法、聊天记录、截图、草稿或部分代码，只是还没有稳定的协作入口。可以把现有材料交给 agent，然后直接复制下面这段话：

请使用 project-collaboration-operating-system，
帮助我为这个项目建立一个最小可用的人与 AI 协作起点。

请先了解我已有的想法、文档和代码，区分已经确认的内容、
暂时的想法、待确认的问题和当前不做的事情。
不要默认创建一整套复杂文档；先说明现在真正缺少什么，
并给出最小方案。得到我的确认后再修改文件。

如果你已经有一个项目

如果项目里已经有代码、README、协作说明或其他文档，但你不确定当前体系是否清楚，可以先做一次协作自检：

请使用 project-collaboration-operating-system，
检查这个项目目前的人与 AI 协作方式。

我不确定现有协作约定是否清楚，也不知道最值得先改善什么。
请先了解项目的代码、文档和当前阶段，说明当前协作现状、
主要风险和建议的下一步。先进行检查，不要修改文件。

最后，请根据检查结果，为我生成一条可以直接复制使用的下一步提示词。

这次检查不是为了给项目打分，也不要求固定增加文档。agent 会判断当前更需要建立入口、整理已有规则、改善一个具体问题，还是复盘一次已经发生的偏航；如果现有体系已经足够，它也应该明确说明不需要为了显得完整而增加流程。

如果你已经知道问题在哪里

你也可以不经过完整自检，直接描述正在发生的问题。例如：

AI 经常没有读完项目上下文就开始工作。请使用
project-collaboration-operating-system 检查项目入口、阅读顺序和文档权威关系，
先诊断原因，不要直接增加新文档。

项目里的规则散落在不同文档中，我不确定哪些内容才算数。请使用
project-collaboration-operating-system 检查重复、冲突、过期或权威不清的规则，
并给出最小的整理建议。

刚才发生了一次人与 AI 的协作偏航。请使用
project-collaboration-operating-system 复盘这次问题，先判断它是执行失误，
还是上下文、文档或流程本身存在问题；只有确认是系统性问题时，才建议修改协作规则。

这些例子只是常见起点，不与某种技术栈、目录结构或项目阶段绑定。你也可以直接用自己的话说明处境，让 agent 判断最合适的下一步。

🛠️ 现在它能帮什么

即使现在仍然很轻，它也已经可以作为一个项目协作体系的初始化工具使用。它比较适合帮你做这些事：

• 📚 梳理文档协作体系：哪些文档是正式规则，哪些只是草稿、审计、截图或临时计划。
• 🚪 建立 AI 读项目的入口：让 agent 不只是读 README 就开始改代码，而是先找到真正权威的上下文。
• 🧱 控制早期工程边界：提醒团队不要过早引入数据库、登录、CI、测试框架、AI 服务等还没到阶段的配置。
• 🔍 检查用户可见行为：避免界面写着“成功”“已保存”“已提交”，但背后没有状态、服务、API 或持久化路径。
• 🔁 做复盘和纠偏：当 agent 或人类协作偏航时，先判断是执行失误、文档歧义、上下文发现失败，还是流程本身缺了一环。
• 🧷 防止文档漂移：当同一条规则出现在多个地方时，帮助团队找到真正的 source of truth，而不是让旧规则悄悄失效。

这些能力还很早期，但它们已经不是纯概念。它们来自真实项目里反复出现的小问题：AI 读错上下文、协作者理解不一致、规则散落各处、完成标准不清楚、复盘只停留在“下次注意”。

🌱 为什么想做它

很多成熟团队和大厂已经有很稳定的 AI 协作流、文档流和工程体系。它们很有价值，也值得学习。

但这些经验通常和完整项目深度绑定：代码结构、测试体系、PR 流程、平台工程、组织记忆、内部工具和长期演进出来的协作习惯都连在一起。对于很多小项目来说，知道它们好是一回事，真的迁移过来是另一回事。

更现实的是，很多项目并不需要一开始就背上很重的工程配置。练手项目、课程项目、黑客松作品、早期创业产品，往往需要的是一套轻量的协作起点：先把最容易出错的地方挡住，再随着项目变复杂，一点点增加更正式的规范、模板、脚本和流程。

所以这个项目想探索的问题不是“怎样一开始就做成最完整的工程体系”，而是：

• 怎样让 AI 协作规范从轻到重地生长？
• 怎样让文档帮助团队行动，而不是变成负担？
• 怎样让一个 skill 可以被复制到不同项目里，而不是和某个项目永久绑定？
• 怎样让非专业开发者也能更容易地参与项目创作和协作？

🧪 初版从哪里来

这个 skill 的初版来自一次很具体的协作经验：作者之前做一个黑客松项目时，需要和很多非技术背景的伙伴一起合作，也需要和不同协作者使用的 agent 对齐项目上下文。

那时的问题不只是“怎么让一个 AI 写代码”，而是“怎么让一群人和一群 AI 不断对齐”：谁的文档更权威，哪些想法还只是草稿，哪些功能现在不能做，怎样本地验证，怎样复盘，怎样让一个协作者的 agent 理解另一个协作者已经沉淀下来的规则。

为了让项目跑起来，作者临时搭了一套文档协作体系、复盘体系和本地测试习惯。后来发现，这套方法论不应该只留在一个项目里，也不应该每次从零重新解释。于是它被整理成了这个更轻量、可迁移的 skill。

💡 我们相信什么

我们相信 AI 时代写代码和做项目不应该只属于技术人员。对技术感兴趣的人，都应该有机会更低成本地开始创作、实验、组织自己的想法。

同时，我们也相信合作中的项目仍然需要一定的秩序。自由创作不等于没有边界，轻量不等于随意，早期不等于不需要反省。

好的工程化配置应该是逐步递增的：先服务协作，再服务规模；先解决真实问题，再增加复杂工具。它应该帮助团队更清楚地行动，而不是为了显得专业而堆叠流程。

🚧 当前状态

这是一个非常早期的概念版本。当前仓库仍然保持很小：一个核心 skill，加上一点参考材料和调用模板，方便复制、阅读、实验和继续修改。

后续我们可能会逐步补充：

• references：更多协作原则、失败模式、判断依据和真实案例压力检查。
• scripts：用于发现文档漂移、重复规则或协作风险的轻量脚本。
• templates：更多可复制的协作说明、决策记录、项目阶段边界等模板。
• examples：来自真实小项目的使用案例、失败案例和改进过程。

这些都还没有定型。我们更希望先把它当成一个开放实验，而不是假装它已经完整。

🔭 我们想继续探索什么

这个项目当然可以只停留在“一个轻量 skill”。但更有意思的地方，可能在于它能不能慢慢长成一套适合小团队的 AI 协作语言。

我们想继续探索一些还没有完全成型、但很值得一起想的方向：

• 🤝 agent-to-agent 协作：未来的项目里，可能不是一个人带着一个 agent 工作，而是一群人带着各自的 agent 一起工作。那不同 agent 之间怎样共享上下文、交接任务、解释规则、互相纠偏？它们需要怎样的“协作协议”？
• 🧳 协作记忆迁移：一个项目里沉淀出来的文档体系、复盘习惯、本地验证方法，能不能被带到下一个项目里？怎样迁移的是方法，而不是复制一堆不适合新项目的文件？
• 🌈 非技术协作者入口：如果一个人不会写工程规范，但很懂产品、内容、设计、运营或真实用户，他能不能通过体验、反馈、案例和复盘参与改进 AI 协作体系？
• 🌿 小项目的渐进式工程化：我们不反对工程化。我们反对的是太早、太重、为了显得专业而引入的工程化。更理想的方式是让规范、脚本、模板和验证随着项目需要一点点长出来。
• 🗂️ 真实失败案例库：AI 读错上下文、误报完成、复盘没有行动、文档规则漂移、协作者的 agent 互相误解，这些都不只是事故，也可以变成可复用的学习材料。

这些想法现在还像草图，不是承诺，也不是路线图。它们更像邀请：如果你也遇到过类似问题，也许我们可以一起把这些模糊的经验变成更清楚、更轻量、更容易迁移的协作工具。

🙌 欢迎一起完善

如果你对这个方向感兴趣，非常欢迎一起参与。

你可以是有经验的开发者，帮助我们判断哪些协作规则真的有用，哪些设计太重、太空或者不适合迁移。

你也可以没有太多研发经验，只是想试着用 AI 做一个项目。你的体验同样重要：哪里看不懂，哪里用不上，哪里让你更有信心，哪里让你更困惑，这些反馈都会帮助这个 skill 变得更好。

也欢迎用它初始化或改善你自己的项目文档体系，做实验，把真实项目里的不顺手带回来，提出 issue，补充例子，改写表达，或者只是 star 一下告诉我们这个方向值得继续。

⭐ Star / 反馈 / 贡献

这个项目现在还很小，也还不完美。它最需要的不是被当成标准答案，而是被更多真实项目试用、质疑、修改和补充。

如果你认同这个方向，欢迎 star、分享、提建议或直接贡献。我们希望它能慢慢长成一个更轻、更实用、更容易迁移的 AI 协作起点。