硅基团队 Silicon Team
一个人如何用 AI 构建一支工程团队 How One Person Builds an Engineering Team with AI
这不是一本"如何用 ChatGPT"的书。这本书讲的是:一个人如何用 AI agent 构建一支工程团队,然后用这支团队交付真实产品。不是 demo,不是概念验证——是有 deadline、有用户投诉、有 production bug 的真实工程项目。
This is not a "how to use ChatGPT" book. It's about how one person builds an engineering team with AI agents and ships real products. Not demos, not proofs of concept — real engineering projects with deadlines, user complaints, and production bugs.
核心论点:约束越好,自由越大。设计好闭环、给好约束、做好角色隔离,按下启动键,去睡觉。醒来检查结果。
Core thesis: Better constraints, greater freedom. Design the closed loop, set the constraints, isolate the roles, press start, go to sleep. Check results in the morning.
S0 先导季 S0 Pilot
一个人 + AI 能做什么? What Can One Person + AI Do?
- 00 00前言:从一个人到一支团队这本书讲的是一个人如何用 AI agent 构建一支工程团队Preface: From One Person to a TeamHow one person builds an engineering team with AI agents
- 01 01协议层:CLI 作为 Protocol LayerCLI 如何解耦 memory 和 agent,以及三层分发模型的设计The Protocol Layer: CLI as Protocol LayerHow CLI decouples memory from agents, and the three-layer distribution model
- 02 02Harness-Native Engineering约束系统设计——Mechanical Gate 如何替代概率性判断Harness-Native EngineeringConstraint system design — how mechanical gates replace probabilistic judgment
- 03 03多硅基协作Agent routing、Spawn vs Delegate、多 agent 编排Multi-Silicon CollaborationAgent routing, Spawn vs Delegate, multi-agent orchestration
- 04 04自主运行OPC pipeline、iterative review、autonomous loopAutonomous OperationThe OPC pipeline, iterative review, and autonomous loops
- 05 05Agent 时代的商业逻辑从工程视角转向商业视角——定位、叙事、投资论点Business Logic in the Agent EraFrom engineering to business — positioning, narrative, investment thesis
- 06 06工程手札17 个用血换来的具体教训Engineering Field Notes17 hard-won engineering lessons
- 07 07从记忆到书227 张卡片如何变成一本书From Memory to BookHow 227 cards became a book
S1 S1
AI 能写代码,凭什么信它? AI Can Write Code — Why Trust It?
- 01 01硅基团队 S1E01: 为什么 AI 能写代码却不能做工程AI 是一个写代码极快的实习生——但它不懂什么是工程。OPC 的故事从这个矛盾开始。Silicon Workforce S1E01: Why AI Can Write Code but Can't Do EngineeringAI is a blazingly fast intern — but it doesn't understand what engineering means. The OPC story begins with this contradiction.
- 02 02硅基团队 S1E02: 一个人的工程团队长什么样4 种角色、14 个节点、1686 行机械规范——OPC 把「让 AI 帮我看看」变成了一条有状态的流水线。Silicon Workforce S1E02: What Does a One-Person Engineering Team Look Like4 roles, 14 nodes, 1686 lines of mechanical spec — OPC turns 'let AI take a look' into a stateful pipeline.
- 03 03硅基团队 S1E03: 从「能跑」到「能信」安全审计 47 分,命令注入、路径穿越、空文件作弊——三周硬化之后,OPC 学会了一件事:不让 AI 变好,让坏后果变小。Silicon Workforce S1E03: From 'It Runs' to 'I Trust It'Security audit score: 47. Command injection, path traversal, empty file cheating — after three weeks of hardening, OPC learned one thing: don't make AI better, make bad outcomes smaller.
- 04 04硅基团队 S1E04: 让框架长出骨骼从 hardcoded 到 capability contract——OPC 的扩展系统设计,以及为什么「关节是扩展点,骨头中间不能挂肌肉」。Silicon Workforce S1E04: Growing a Skeleton for the FrameworkFrom hardcoded to capability contracts — OPC's extension system design, and why 'joints are extension points, you can't hang muscles in the middle of a bone.'
- 05 05硅基团队 S1E05: 睡觉的时候让 AI 替我干活我跟 AI 说「跑完再来找我」,然后去睡觉了。几个小时后回来,一句话就让分数从 0.487 跳到了 0.68——不是因为 AI 做得好。Silicon Workforce S1E05: AI Works While You SleepI told AI 'finish up and come find me,' then went to bed. Hours later I checked back — one sentence pushed the score from 0.487 to 0.68. Not because AI did great work.
- 06 06硅基团队 S1E06: $92 买了一个产品23 小时、$92、44 个 AI 员工——从零到一个完整产品的真实账单。以及为什么 Loop 执行计划,不生成计划。Silicon Workforce S1E06: $92 Bought a Product23 hours, $92, 44 AI employees — the real bill from zero to a complete product. And why loops execute plans, they don't generate them.
- 07 07硅基团队 S1E07: 当工具开始检查自己用 OPC 审计 OPC,所有 gate 都 PASS——这才是最大的问题。一个关于镜子、洋葱和盲点的故事。Silicon Team S1E07: When Tools Start Checking ThemselvesUsing OPC to audit OPC, every gate PASS — that's the real problem. A story about mirrors, onions, and blind spots.
- 08 08硅基团队 S1E08: AI 跑了 8 小时后忘了自己是谁跑到第 8 个 tick,AI 开始重复工作。它忘了自己刚修过这个 bug。因为它的记忆被压缩掉了。Silicon Workforce S1E08: AI Ran for 8 Hours and Forgot Who It WasBy tick 8, AI started repeating work. It forgot it had just fixed this bug. Because its memory got compressed away.
- 09 09硅基团队 S1E09: 不让 AI 变好,让坏后果变小OPC 所有设计决策背后的同一个原则:不要优化 AI 的能力,要优化它出错时的后果。Gate 是底线不是来源,AI 能做相对判断不能做绝对评价。Silicon Team S1E09: Don't Make AI Better, Make Bad Outcomes SmallerOne principle behind every OPC design decision: don't optimize AI's capability, optimize the consequences when it fails. Gates are floors, not sources. AI can make relative judgments, not absolute ones.
- 10 10硅基团队 S1E10: 人什么时候该介入AI 跑了 23 小时方向全错,一句话就扳回来了。autonomous loop 不是不需要人,而是需要人在对的时间说对的话。Silicon Team S1E10: When Humans Should Step InThe AI ran 23 hours in the wrong direction. One sentence fixed it. Autonomous loops don't eliminate humans—they redefine when humans matter.
- 11 11硅基团队 S1E11: 翻车之后怎么办Gate 全绿但封面图缩了 40%。review 系统 review 自己时崩了。当安全网本身有洞,修复不是回滚——是让系统学到教训。S1 终章。Silicon Team S1E11: After the CrashGates all green, but the cover image shrunk 40%. The review system crashed when reviewing itself. When safety nets have holes, recovery isn't rollback—it's making the system learn. S1 finale.
S2 S2
有了可靠 AI,能做出什么? With Reliable AI, What Can You Build?
- 01 01硅基团队 S2E01: 扳回方向之后,产品才刚开始S1E10 扳回了方向,但代码还是那套 Tailwind 管理后台。LLM Pool 三路回退、Apple 设计令牌、WCAG 对比度——从方向正确到产品可用之间,是密度最高的打磨。Silicon Team S2E01: A Family Product in 23 Hours for $92One-sentence requirement, 44 AI subagents, 35 commits. Direction completely wrong midway, corrected by a single sentence. The two-day journey from zero to MVP.
- 02 02硅基团队 S2E02: 40 个 Tick 推上线47 小时,$347,3 次上下文溢出。把一个散乱的单用户工具推到云端生产环境——五次部署调试,以及一个跑完了不肯停的循环。Silicon Team S2E02: 40 Ticks to Production47 hours, $347, 3 context blowouts. Turning a single-user tool into SaaS — and the most ironic bug was the AI that wouldn't stop.
- 03 03硅基团队 S2E03: 所有人都说通过的时候该担心了四个审查者全判 PASS,没有一个质疑方向。加了第十人之后,第一次审查就发现了「想象力的失败」。共识不是推进的信号,是需要挑战的信号。Silicon Team S2E03: When Everyone Says PASS, It's Time to WorryFour reviewers unanimously judged PASS — not one questioned direction. After adding the Tenth Man, the very first review uncovered 'a failure of imagination.' Consensus isn't a signal to proceed — it's a signal to challenge.
- 04 04硅基团队 S2E04: 动手之前先看别人踩过的坑30 个开源 AI 项目拆开看:上帝文件三基因、插件困难三角、标准化代价、测试密度不等于成功。每个发现都回扣了一个设计决策。先看别人踩过的坑,再决定自己踩哪个。Silicon Team S2E04: Look at Others' Pitfalls Before Digging Your Own30 open-source AI projects dissected: God File three genes, the plugin difficulty triangle, the cost of standardization, and test density ≠ success. Each finding calibrated a design decision. Look at others' pitfalls before choosing which ones to step in yourself.
- 05 05硅基团队 S2E05: 每做一个新产品,核心就胖一圈两个产品做下来,核心代码从 800 行胖到 2000 行。能力合约让扩展和核心互不认识,五种钩子切入流水线的五个阶段,熔断器保证一个坏扩展不会拖死整条线。Silicon Team S2E05: Every New Product Makes the Core FatterAfter two products, core code grew from 800 to 2,000 lines. Capability contracts let extensions and core ignore each other, five hook types cut into five pipeline phases, and a circuit breaker ensures one bad extension can't kill the line.
- 06 06硅基团队 S2E06: 三个审查者没一个看出颜色不对教育工具前端重构后,两个蓝色相差 7 度色相,安全、后端、前端三个审查者全部 PASS。Design Intelligence 给流水线装了调色板护栏、28 个 AI 嗅探器和参考层——让机器看得见设计。Silicon Team S2E06: Three Reviewers and Not One Noticed the Wrong ColorAfter the education tool's frontend refactor, two blues differed by 7 degrees of hue. Security, backend, and frontend reviewers all PASS. Design Intelligence gave the pipeline a palette guardrail, 28 AI smell detectors, and a reference layer — teaching machines to see design.
- 07 07硅基团队 S2E07: 看不到过程,就没法信结果JSON 日志没人看,审查报告无人读。opc-viewer 把 AI 团队的审查过程变成对话回放——16 个虚拟团队成员有名字、有头像、有颜色。看不到过程,就没法信结果。Silicon Team S2E07: If You Can't See the Process, You Can't Trust the ResultNobody reads JSON logs. Nobody reads review reports. opc-viewer turned the AI team's review process into a conversation replay — 16 virtual team members with names, avatars, and colors. If you can't see the process, you can't trust the result.
- 08 08硅基团队 S2E08: 让工具审自己,发现它从没拦过谁用 OPC 审 OPC 自己,14 个节点全 PASS——FAIL 路径从未被触发。一个从未行使过的强制机制,和一个不存在的强制机制,没有区别。Silicon Team S2E08: Letting the Tool Audit Itself — and Finding It Never Blocked AnyoneUsed OPC to audit OPC itself; all 14 nodes PASS — the FAIL path was never triggered. An enforcement mechanism that has never been exercised is indistinguishable from one that doesn't exist.
S3 S3
AI 工具是怎么造出来的? How Are AI Tools Built?
- 01 01硅基团队 S3E01: 第二个人不是没来,是卡在门口163 stars,39 forks。然后第一个真正有价值的反馈来了——不是夸奖,而是:Linux 上跑不起来。skill.md 和 SKILL.md 之间的距离,就是'我能用'和'别人也能用'之间的距离。Silicon Team S3E01: The Second User Didn't Not Show Up — They Got Stuck at the Door163 stars, 39 forks. Then the first truly valuable feedback arrived — not praise, but: 'It doesn't run on Linux.' The distance between skill.md and SKILL.md is the distance between 'I can use it' and 'others can use it.'
- 02 02硅基团队 S3E02: 他们敢加角色,但不敢碰核心五个 PR,五个新角色——Performance、Technical Writer、Localization、Data Engineer、SRE。全部只改 roles/*.md,全部遵循四段式格式。零个 PR 碰 harness、gate 或 review flow。信任先转移到最安全的接口。Silicon Team S3E02: They Add Roles, But Won't Touch the CoreFive PRs, five new roles — Performance, Technical Writer, Localization, Data Engineer, SRE. All only modify roles/*.md, all follow the four-section format. Zero PRs touch harness, gate, or review flow. Trust transfers to the safest interface first.
- 03 03硅基团队 S3E03: 为什么角色系统能被外部理解五个角色 PR 都遵循了四段式格式。不是因为文档写得好,而是因为接口设计暗含了三个信号:看得懂、改得动、改坏了不怕。低风险贡献面是信任转移的入口。Silicon Team S3E03: Why the Role System Could Be Understood by OutsidersAll five role PRs followed the four-section format. Not because documentation was good, but because the interface design implicitly signaled three things: understandable, modifiable, and safe to break. Low-risk contribution surfaces are the entry point for trust transfer.
- 04 04硅基团队 S3E04: 没人碰 gate,说明核心还不是公共资产28 个 PR,0 个外部贡献者碰 harness/gate/review flow。不是他们胆小,是核心没有发出'可改'的邀请。代码公开不等于理解公开——权衡、放弃的方案、历史 bug 的上下文全锁在作者脑子里。Silicon Team S3E04: Nobody Touched the Gate — The Core Isn't a Public Asset Yet28 PRs, 0 external contributors touching harness/gate/review flow. They're not timid — the core never issued an invitation to change it. Public code doesn't mean public understanding — tradeoffs, abandoned alternatives, and historical bug context are all locked in the author's head.
- 05 05硅基团队 S3E05: 把个人工具改成陌生人能跑的工具一个文件名的大小写牵动了 11 个文件。但 #21 只是冰山一角——路径硬编码、配置分层缺失、会话(session)隔离不存在、崩溃恢复靠手动。把个人工具改成公共工具,不是 polish,是重建信任的地基。Silicon Team S3E05: Turning a Personal Tool Into Something a Stranger Can RunOne filename's capitalization rippled across 11 files. But #21 was just the tip of the iceberg — hardcoded paths, missing config layers, no session isolation, manual crash recovery. Making a personal tool public isn't polish — it's rebuilding the foundation of trust.
- 06 06硅基团队 S3E06: 第一次真正验证 FAIL 路径S1-S2 最大的未偿还技术债:八个产品,几十次门禁,回环机制一次都没触发过。安全网必须被测试过才算安全网——你自己不测,别人更不会信。Silicon Team S3E06: Actually Verifying the FAIL Path for the First TimeS1-S2's biggest unpaid technical debt: eight products, dozens of gates, the loop mechanism never triggered once. A safety net must be tested to count as a safety net — if you don't test it, nobody else will trust it.
- 07 07硅基团队 S3E07: 从角色贡献到扩展生态,中间差一个治理层五个角色 PR 没有统一的 review 标准——谁来判断一个角色'够好'?接受贡献不等于有能力治理贡献。没有治理的开源不是生态,是堆积。Silicon Team S3E07: Between Role Contributions and an Extension Ecosystem, There's a Missing Governance LayerFive role PRs with no unified review standard — who decides when a role is 'good enough'? Accepting contributions doesn't equal the ability to govern contributions. Open source without governance isn't an ecosystem — it's accumulation.
- 08 08硅基团队 S3E08: 信任转移的五层账本三季回看:S1 建立信任,S2 压力测试信任,S3 扩展信任。163 stars 是一个数字,五层账本是一个结构。工具的生命周期不是 build → ship → done,是 build → ship → 有人来了 → 发现信任只转移了一层 → 继续修。Silicon Team S3E08: The Five-Layer Trust Transfer LedgerThree-season lookback: S1 established trust, S2 stress-tested trust, S3 extended trust. 163 stars is a number; the five-layer ledger is a structure. A tool's lifecycle isn't build → ship → done — it's build → ship → people arrive → discover trust only transferred one layer → keep fixing.
📬 订阅更新 📬 Subscribe for updates
新章节、勘误和 AI 工程实战更新。 New chapters, errata, and AI engineering updates.
写于 2026 年 3-5 月 · 基于 227 张 Zettelkasten 卡片 + 176 篇工程日志 · AI + 人类协作产出
Written March–May 2026 · Based on 227 Zettelkasten cards + 176 engineering logs · AI + human collaboration