构建AI原生的软件开发生命周期

Alex Lieberman 2026-08-07 19.9 KB 64K 95 𝕏 文章列表

随着AI编程智能体的兴起，传统的敏捷开发流程已无法有效扩展。文章深入解析了Tenex团队开发的AI原生软件开发生命周期系统——MetaHarness。该系统旨在解决智能体执行速度超越系统上下文维护能力的风险，提出了将“上下文即代码”、制定允许动态调整的详细计划等八大核心原则。通过引入严格的文档语法、单一事实来源以及连接紧密的工程蓝图，MetaHarness实现了人机高效协作，使软件开发变得更快速、健壮且可衡量。

# Building an AI-Native SDLC **作者**: Alex Lieberman **日期**: 2026-08-06T15:12:47.000Z **来源**: [https://x.com/businessbarista/status/2085383591475773666](https://x.com/businessbarista/status/2085383591475773666) --- ![Image](/doc/3954/image/img_eae8d952d23c.jpg) Breaking down MetaHarness, the system behind @tenex_labs' SDLC, the principles it runs on, and what changes when coding agents become partners in development. Co-authored by Alex Lieberman, @ArmanHezarkhani, @dan_zakon, and @seejayhess. Full article here: https://www.tenex.co/blog/building-an-ai-native-sdlc > "On days where everything works well, I can't help but think nothing I do matters, everything is automated and better and faster than I ever will be. But then there are days where everything breaks and I don't understand why and I realize I have no idea what I've been up to anymore." The anonymous Anthropic engineer put words to something we've all felt since the release of Sonnet 3.5. The defining risk of agentic software development is that execution can now scale faster than the systems engineers use to preserve context, coherence, and understanding. But coding agents do not have to make software development less legible. Paired with a process designed for human-agent collaboration, they make possible an SDLC that is faster, more robust, more repeatable, and better documented than what came before. This essay describes the principles & process behind MetaHarness, the system that runs Tenex's AI-native SDLC, & how you can deploy a similar system within your engineering org. ## The evolution of SDLC The development process is a dance between collaboration and coherence. And as technology has evolved, so too has the manner in which engineering teams work together to keep a system coherent. Waterfall tried to make software predictable by proactively mapping an entire system. Winston Royce published the cascade diagram in 1970. In the same paper, he warned that building this way "is risky and invites failure." The industry kept the diagram and dropped the warning. Unknown unknowns are a property of software, and a process that depends on predicting the future is highly fragile. The Agile Manifesto was the practical response, written in 2001 by seventeen developers at a ski lodge in Snowbird, Utah. Instead of pretending the team could know everything at the start, it organized work into small increments and relied on frequent conversation. An engineering org carried a surprising amount of context through standups, pairing, reviews, and the collective memory of a group building for 12 hours a day together. That is the part agents change. An engineer remembers yesterday's huddle, notices that a ticket conflicts with a prior decision, and knows which document is stale based on live discussion. A coding agent has no such luxury. Agile could leave project state implicit because people carried it from one day to the next. Agents cannot inherit what was never written down. So the mechanism (read: agile) that produced coherence does not scale with cold-blooded companions (read: agents). More execution capacity amplifies the quality of the shared plan, including its omissions. Once 100 coding agents work on one system, a shared blueprint stops being planning overhead. It becomes the only thing stopping a build from going off the rails. ## The lifecycle At face value, our AI-native SDLC appears unremarkable. It runs a loop of phases not dissimilar from Waterfall or agile. ![Image](/doc/3954/image/img_622641ffd34f.jpg) What changes when agents do the work is what happens inside the loop: how much gets written down, who reads it, and what gets checked before work moves on. The essence of MetaHarness reduces to eight principles: 1. Context as code. 2. Plans are detailed, and allowed to change. 3. Every agent starts senior. 4. Skills ship like software. 5. One record, many views. 6. Let agents check their own work. 7. Status is derived, not reported. 8. Lessons compound for everyone. ![图片](/doc/3954/image/img_250ca5d06a23.jpg) ## Context becomes part of the system Principle 1: Context as code. We treat context as code. If project context determines what agents build, it needs the properties we expect from source code: one home, versioned and reviewable changes, known shapes, checkable relationships, detectable staleness. We call this home the project record: a source of truth holding everything a project knows about itself, sitting in the repo next to the code base. It works the way double-entry bookkeeping does. Both sides have to balance, and a discrepancy is an error you can point at rather than a game of he said she said. What is true, what is planned, and what happened are recorded separately, cross-referenced, and checked. The names are ours and yours would differ, but the shape underneath matters. Every project gets a git repo of markdown with strict grammar. Current truth lives in 1-docs/, intent splits between 2-epics/ and 3-project-specs/, history goes in 4-log/, and anything archived moves under .archived/, where the tooling refuses to write. Filenames follow a pattern the parser knows, so ARCH-system-overview.md is a record and arch_system_overview.md is an error with a fix suggested. ![Image](/doc/3954/image/img_1044bce21150.jpg) 6-scratchpad/ exists so the others can stay pristine. If there is nowhere to put a messy thought, people put messy thoughts into the canonical documents. A governed system needs an ungoverned annex, or the governance leaks. Inside each planning file, the boundary is about who may write, not what the system may read. People edit the prose freely. The CLI parses the whole document, but when it syncs from Linear or GitHub it only rewrites the fenced blocks reserved for machine output: external IDs, status, metadata. The reasoning around those blocks is never touched. It is a mutex expressed as syntax. ![Image](/doc/3954/image/img_5e54b2ad8557.jpg) ## A blueprint that is allowed to change Principle 2: Plans are detailed, and allowed to change. Historically, engineers had to be selective about time spent on planning & documentation. Hours were finite & competition against time spent ripping code was real. Agents collapsed that cost. It is now affordable to build a much more complete blueprint of a large system before implementation starts, and to keep it current as the work changes. That blueprint gives every person and agent the same account of what we are building, why it matters, and what must be true before the work is accepted. The artifacts are useful to humans and force agents to behave deterministically. Moreover, deeply opinionated structure is must-have. Every ticket belongs to exactly one MetaHarness checkpoint or is explicitly exempted. A spec with tickets and no checkpoints is an error. And acceptance criteria aren't committed to memory; a criterion belongs to a ticket, making pass/fail legible to agents. This is more planning than many agile teams would consider economical, and it is not a return to a fixed specification. We still work in sprints, epics, milestones, tickets, and demos, and we still expect plans to change once the team learns something. The difference is that these parts belong to one connected blueprint rather than a set of loosely related tracker entries, which also makes readiness measurable: how much work is scoped ahead, and where the plan runs out. That gives our engineering managers an early warning before a team reaches the end of its prepared work. ## We practice benevolent prompt injection Principle 3: Every agent starts senior. Maintaining context hygiene is half the problem. The process also has to deliver it at the moment an agent begins working. An agent opening ticket 3 on a payments spec does not start with a blank prompt. It starts with the architecture doc, the two decisions logged last week, the acceptance criteria that define done for that ticket, the fact that validation is currently clean, and the commands that let it verify its own claims. Managed startup hooks assemble that packet automatically, across the agent environments our engineers use. We like to think of this as benevolent prompt injection. We inject the project's rules, requirements, process, and current state before the task begins, so a new session does not depend on a user starting with the right prompt. No session starts junior. A new agent follows yesterday's conventions, an agent waking after a pause inspects current state instead of trusting an old snapshot, and a replacement takes over without a person retelling the story. ## Tribal knowledge is embodied by shared skills Principle 4: Skills ship like software. The instructions agents receive are managed as a shared company system rather than a collection of personal prompts. Tenex maintains more than fifty reusable skills. There is one for writing a project spec, one for executing a ticket against its acceptance criteria, one for investigating a bug, one for preparing a pull request, one for reviewing whether a doc still matches the code. A skill loads when the task calls for it and stays out of unrelated sessions, so an agent gets detailed guidance without carrying the whole company handbook in every context window. They are versioned, tested against fixtures, and released through standards channels, so a process change rolls out deliberately. An engineer can change tools without losing the firm's way of planning, reviewing, and shipping work. This is how a local lesson becomes company capability. When one project finds a better way to review an architecture or validate a release, that improvement goes into the relevant skill and every future session inherits it. ## The development process has a machine interface Principle 5: One record, many views. Without a machine interface, an agent working in your repo has to read files and guess. The Tenex CLI removes the guesswork & enforces guardrails (through 30+ commands) so engineers don't need to babysit the codebase. An agent asks what is true, what is ready, what is broken, what happens next, and gets structured facts. Examples: - Which tickets are unblocked. - Where the record and Linear disagree. - What required sections of plans are missing or invalid. - Make Linear match the markdown. - Approval of acceptance criteria. Every answer is grounded in the project record, so an agent is never working off stale source of truth. Writes to Linear and GitHub work the way infrastructure tools have for a decade: you see the full plan before anything executes, and applying it takes a separate deliberate step. If a ticket could plausibly match two Linear issues, it refuses and names both. The value of the Tenex CLI is that a write to Linear is either correct or it doesn't happen. If the project record is the blueprint, the CLI is what turns it into work orders and sounds the alarm when Linear stops matching the blueprint. ## Validation makes autonomy safer Principle 6: Let agents check their own work. Agents must be kept on a leash, because they can be convincing and wrong. So trust is earned through verification. Plans are checked for missing relationships, tickets against their acceptance criteria, documentation against the code. The checks also give an agent a way to repair its own work. tenex validate returns something like PS-portal ticket 6 points at milestone M3, which does not exist; relink or remove. Guidance that's precise enough for the agent to self-heal and run the check again, with no human intervention needed. Long tasks stop depending on an agent holding a perfect chain of reasoning for hours. What gets to the engineer is an error the agent couldn't self-correct. An agent marking a ticket done when nothing links to a PR, tests, or a sign-off does not get to make that claim stick. ![Image](/doc/3954/image/img_2b93265f710e.jpg) An agent becomes more useful when it has the context to understand the objective, the tools to act, a bounded authority, observable criteria for progress, durable state, and a clear escalation path. Removing those constraints would not make it freer, only less certain, and would put a human back in the loop to repair the ambiguity. The goal was never maximum autonomy. It is to remove unnecessary dependence on human attention while making the moments that genuinely need a person easier to spot. ## Tenex OS makes the process legible to the team Principle 7: Status is derived, not reported. The same structured state powers Tenex OS, our human-facing surface. An engineer examines the work closest to the build, an engineering manager is kept abreast of planning and quality risk, and leadership can scan delivery health across all projects. A status report built off of memory is subjective at best, lossy at worst. When epics, specs, tickets, branches, and PRs are connected the system provides a verifiable source of truth & flags disagreements. If the system says a ticket is complete but evidence is missing, the inconsistency becomes visible. There are no surprises. ![图片](/doc/3954/image/img_83bdaae19ed2.jpg) ## The process learns from the work Principle 8: Lessons compound for everyone. Each project can improve the system used to run the next one. A repeated planning gap becomes a new check. A useful way of investigating a codebase becomes a skill. A decision that keeps causing confusion becomes an explicit convention. A manual status reconciliation becomes a CLI command. Traditional organizations learn too, but that learning spreads through people, onboarding, and team culture. The added opportunity is to encode a lesson so it changes the default behavior of every relevant session, so improvements travel as tested, versioned changes instead of advice that depends on everyone hearing and remembering it. This is why the process itself becomes a durable asset. The client still gets the software, and the team gets better at producing software, because the system around the work retains what it learned. ## What the process expects of people An SDLC this automated can imply judgment has also been automated. This couldn't be further from the truth. If anything, the standard we hold each other to continues to climb. Agents are like funhouse mirrors. Used well, they make a strong engineer dramatically more capable. Used carelessly, they let weak fundamentals produce spaghetti code and slop. The system multiplies judgment, it does not supply it. Let's be clear: the job of an engineer has changed shape. Engineering is higher level and multithreaded now: articulating intent and architecture clearly enough that many agents can act on it, taking on harder problems because the cost of attempting them fell, steering a fleet of agents efficiently across time and tokens, and keeping the codebase from decaying while all of that happens at once. So the output is yours. There is no such thing as "Claude told me to do it." If you merge it, send it, or show it to a stakeholder, you are accountable for it being right, and reading what you shipped is not optional. You make your bed. You're responsible for sleeping in it. ## Where to start You can start this today, for free, in any codebase. It takes one project and a few weeks of discipline. If we were starting over, this is the order we would do it in. Start with three folders, not seven. What is true now, what we intend to build, and what happened. Put them in the repository next to the code, in markdown, and resist designing a taxonomy before you have used one. Add the scratchpad fourth, sooner than you expect, because the alternative is people putting rough notes into the canonical documents. Write one blueprint, for one real project. What you are building, why it matters, the major boundaries and decisions, the next few slices of work, and what must be true before each is accepted. This is the artifact that does the most work, and writing it with an agent takes hours rather than days. Adopt the fence rule on day one. Decide which parts of a document a machine may rewrite and mark them off, whether that is a code fence, a comment marker, or a separate file. Retrofitting this means untangling every document where a sync has already overwritten someone's prose. Add one validator, however small. A script that flags tickets pointing at milestones that do not exist, or documents untouched since the architecture changed. One check is enough to change the failure mode: drift starts producing a failing check instead of a quiet surprise six weeks later. Give every session the same starting packet. Assemble it from those files, so orientation stops depending on whoever wrote the prompt that morning, and derive one view of project health from the record instead of asking a person to write one. Then watch where it strains. Wherever the record is missing, stale, or wrong is where your process currently runs on memory, and each one you fix compounds. Two honest limits. Below a certain size this is overkill: one team on one project drifts slowly enough that the ceremony costs more than it saves, and the approach pays for itself as concurrency grows. And it depends on one commitment technology cannot supply, which is writing things down. Validation exists because discipline alone eventually fails, but a team that refuses to write anything down has a different problem to fix first. ## What is actually different The old tradeoff placed detailed planning on one side and speed on the other, because humans maintained every part of the process by hand. Agents change that tradeoff. Structure increases speed when it removes repeated discovery, prevents incompatible work, gives every agent a reliable starting point, and makes failures easier to detect and repair. The practical test is whether a new agent can enter a project, understand the intended system, choose work that fits the current plan, load the company's method for doing that work, prove what it changed, and leave the project easier for the next agent to understand. The test for the organization is whether engineers and managers can inspect that work across many projects without reconstructing reality from meetings and manually updated dashboards. If both are true, coding agents become more than faster implementers. They become participants in a development system that can take on more complexity without losing the thread. Work with Tenex Whether you're an engineering leader looking to reimagine your SDLC to be AI-native, or an enterprise executive trying to solve your hardest technical challenges with an A-team of forward deployed engineers, we can support you. Join Tenex If you're an AI-native engineer looking to live on the frontier and ship production AI systems for clients whose codebases run businesses worth billions. Join the team. ## 相关链接 - [Alex Lieberman](https://x.com/businessbarista) - [@businessbarista](https://x.com/businessbarista) - [48K](https://x.com/businessbarista/status/2085383591475773666/analytics) - [@tenex_labs](https://x.com/@tenex_labs) - [@ArmanHezarkhani](https://x.com/@ArmanHezarkhani) - [@dan_zakon](https://x.com/@dan_zakon) - [@seejayhess](https://x.com/@seejayhess) - [https://www.tenex.co/blog/building-an-ai-native-sdlc](https://www.tenex.co/blog/building-an-ai-native-sdlc) - [Agile Manifesto](https://agilemanifesto.org/) - [we can support you](https://www.tenex.co/ai-transformation) - [Join the team](https://www.tenex.co/careers) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [11:12 PM · Aug 6, 2026](https://x.com/businessbarista/status/2085383591475773666) - [48.6K Views](https://x.com/businessbarista/status/2085383591475773666/analytics) - [View quotes](https://x.com/businessbarista/status/2085383591475773666/quotes) --- *导出时间: 2026/8/7 22:01:27* --- ## 中文翻译 # 构建AI原生的软件开发生命周期 **作者**: Alex Lieberman **日期**: 2026-08-06T15:12:47.000Z **来源**: [https://x.com/businessbarista/status/2085383591475773666](https://x.com/businessbarista/status/2085383591475773666) --- ![Image](/doc/3954/image/img_eae8d952d23c.jpg) 深度解析 MetaHarness——@tenex_labs 软件开发生命周期（SDLC）背后的系统、它所遵循的原则，以及当编程智能体成为开发伙伴时，一切将发生怎样的改变。由 Alex Lieberman、@ArmanHezarkhani、@dan_zakon 和 @seejayhess 共同撰写。全文链接：https://www.tenex.co/blog/building-an-ai-native-sdlc > “在一切顺利的日子里，我忍不住会想，我做的一切都无关紧要，所有的东西都被自动化了，而且比我以往做得更好、更快。但也会遇到一切都崩溃的日子，我搞不懂为什么会这样，我甚至意识到自己完全不知道我整天到底在捣鼓些什么。” 这位匿名的 Anthropic 工程师道出了自 Sonnet 3.5 发布以来，我们所有人的心声。智能体化软件开发的决定性风险在于，现在代码执行的速度，可以轻易超过工程师用来保持上下文、连贯性和理解力的系统承载极限。但编程智能体并不一定会让软件开发变得难以理解。配合专为“人机协同”设计的工作流，它们能够打造出一个比以往任何时候都更快捷、更稳健、更具可重复性且文档更完善的软件开发生命周期（SDLC）。这篇文章介绍了 Tenex 用以运行其 AI 原生 SDLC 的底层系统——MetaHarness 背后的原则与工作流，并探讨了如何在你自己的工程团队中部署类似的系统。 ## 软件开发生命周期的演进开发过程是协同与连贯性之间的共舞。随着技术的演进，工程团队在保持系统连贯性方面的协作方式也在不断变化。瀑布流模式试图通过主动描绘整个系统来让软件开发变得可预测。温斯顿·罗伊斯在 1970 年发表了著名的瀑布流图表。但在同一篇论文中，他警告说这种构建方式“充满风险且容易导致失败”。然而，整个行业只保留了图表，却忽视了警告。“未知的未知”是软件工程的固有属性，一个依赖于预测未来的开发流程是极度脆弱的。敏捷宣言是一次务实的回应，它由十七位开发者于 2001 年在犹他州雪鸟市的一间滑雪木屋里共同起草。它不再假装团队能够在项目之初就知晓一切，而是将工作划分为一个个小的增量，并依赖于频繁的沟通。工程团队通过每日站会、结对编程、代码审查，以及每天在一起共同构建长达 12 个小时所凝聚的集体记忆，来承载巨量的项目上下文。而这正是智能体所改变的部分。人类工程师会记得昨天的简会，能敏锐察觉某个任务与之前的决策相冲突，并清楚基于实时讨论哪份文档已经过时。编程智能体却没有这种“特权”。敏捷开发之所以能将项目状态隐式化，是因为人们会在日复一日的交替中将其铭记在心。智能体却无法继承那些从未被写下的事物。因此，这种曾用于构建连贯性的机制（即敏捷开发），在面对“冷血”的伙伴（即智能体）时无法进行有效扩展。更多的执行能力会放大共享计划的缺陷——包括那些被遗漏的部分。一旦 100 个编程智能体同时在同一个系统上工作，一份共享的蓝图就不再是所谓的“计划开销”。它将成为唯一能防止整个构建过程失控的救命稻草。 ## 生命周期从表面上看，我们的 AI 原生 SDLC 似乎平淡无奇。它同样运行着与瀑布流或敏捷开发截然不同的循环阶段。 ![Image](/doc/3954/image/img_622641ffd34f.jpg) 当智能体接管工作时，真正发生改变的是循环内部的事情：有多少信息被记录了下来，是谁在读取这些信息，以及在进入下一步之前需要进行哪些检查。 MetaHarness 的核心理念可以归结为八项原则： 1. 上下文即代码。 2. 计划须详尽，且允许变更。 3. 每个智能体一上线即是“高级工程师”。 4. 技能如同软件般发布。 5. 单一记录，多维视角。 6. 让智能体自查工作。 7. 状态是推导出来的，而非汇报出来的。 8. 经验教训为所有人不断复利。 ![图片](/doc/3954/image/img_250ca5d06a23.jpg) ## 上下文成为系统的一部分原则 1：上下文即代码。我们将上下文视为代码。既然项目上下文决定了智能体构建什么，它就必须具备我们对源代码所期望的属性：唯一的归宿、可版本控制及可审查的更改、已知的数据结构、可检查的关系以及能被检测到的过时信息。我们称这个归宿为“项目记录”：它是项目所有自我认知的事实来源，存放在代码库旁的版本库中。它的工作原理就像复式记账法。账目的两边必须平衡，任何差异都是一个明确指向的错误，而不是一场“公说公有理，婆说婆有理”的推诿。什么是事实、什么是计划、以及发生过什么，这些信息会被分开记录、相互参照并进行校验。具体的命名因团队而异，但底层的逻辑架构至关重要。每个项目都拥有一个包含严格语法的 Markdown 代码库。当前的“事实”存放在 `1-docs/` 中，意图在 `2-epics/` 和 `3-project-specs/` 中拆分，“历史”记录在 `4-log/` 中，而任何被归档的内容都会移至 `.archived/` 目录下，并且系统工具会被禁止写入该目录。文件名遵循解析器能够识别的模式，因此 `ARCH-system-overview.md` 是一条合法的记录，而 `arch_system_overview.md` 则是一个报错，并会提示修正建议。 ![Image](/doc/3954/image/img_1044bce21150.jpg) 设置 `6-scratchpad/`（草稿区）是为了让其他目录保持纯净。如果没有地方安放那些杂乱无章的想法，人们就会把这些杂念写进核心的规范文档里。一个受严格管理的系统需要一个不受管辖的“附庸”，否则管理规则就会遭到破坏。在每个计划文件内部，边界在于“谁可以写入”，而不是“系统可以读取什么”。人类可以自由编辑散文式的文本说明。命令行界面（CLI）会解析整个文档，但当它从 Linear 或 GitHub 同步信息时，只会重写那些专门为机器输出预留的隔离区块：如外部 ID、状态、元数据。围绕这些区块的推理分析内容绝不会被触碰。这是一种通过语法表达的互斥锁机制。 ![Image](/doc/3954/image/img_5e54b2ad8557.jpg) ## 允许变更的蓝图原则 2：计划须详尽，且允许变更。从历史上看，工程师不得不有选择性地分配用于规划和文档编写的时间。时间是有限的，且与编写核心代码的时间存在着实实在在的竞争。智能体将这种成本大幅压缩。如今，在开始实施之前构建一份非常完整的大型系统蓝图，并在工作发生变化时使其保持最新，是完全负担得起的。这份蓝图让每个人和每个智能体对我们正在构建什么、为什么重要，以及在交付工作前必须满足什么条件，有着完全一致的认知。这些产出物对人类非常有用，同时也迫使智能体的行为具有确定性。此外，具有强烈约束的结构是必不可少的。每个任务工单必须精确归属于一个 MetaHarness 检查点，或者被明确豁免。一个包含工单但没有检查点的规范会被视为错误。验收标准也不能仅仅停留在记忆中；一个标准必须从属于特定的工单，使得智能体能够清晰辨别“通过/失败”的界限。这种规划程度在许多敏捷团队看来并不经济，但它也绝非回到那种固定规格说明书的老路。我们依然在迭代周期、史诗需求、里程碑、工单和产品演示中工作，我们依然预期计划会随着团队获取新认知而发生改变。不同之处在于，这些组成部分如今被整合到了一份相互连接的蓝图中，而不是一系列松散相关的追踪器条目。这也让“准备就绪度”变得可衡量：有多少工作已提前规划好，以及计划的边界在哪里。这能为我们工程团队的负责人提供预警，避免团队在耗尽已准备好的工作后才陷入被动。 ## 我们践行善意的提示词注入原则 3：每个智能体一上线即是“高级工程师”。保持上下文的整洁只是解决问题的一半。工作流程还必须在智能体开始工作的那一刻，准确地将上下文交付给它们。当一个智能体打开某个支付规范上的 3 号工单时，它启动时面对的绝不是一张白纸。它的初始上下文包含了架构文档、上周记录的两项决策、定义该工单何为“完成”的验收标准、当前验证无误的事实，以及让它验证自身声明是否正确的相关命令。托管的启动钩子程序会跨我们工程师使用的各种智能体环境，自动组装好这份数据包。我们喜欢把这看作是一种“善意的提示词注入”。我们在任务开始前，将项目的规则、需求、流程和当前状态注入进去，从而使得一次新的对话不再依赖于用户是否以正确的提示词开始。没有哪次会话是从“初级”开始的。一个新的智能体会遵循昨天确立的惯例；一个在暂停后重新唤醒的智能体会主动检查当前状态，而不是盲目信任旧的快照；一个接替的智能体可以无缝接管工作，而无需人类重新讲述前情提要。 ## 部落知识由共享技能具象化原则 4：技能如同软件般发布。智能体接收到的指令是被当作公司共享的系统来管理的，而不是一堆个人的提示词大杂烩。 Tenex 维护着 50 多个可复用的技能。有专门用于编写项目规范的技能，有根据验收标准执行工单的技能，有用于调查 bug 的技能，有用于准备拉取请求（PR）的技能，还有用于审查文档是否仍然匹配代码的技能。当任务需要时，某个技能会被加载；而在无关的会话中它则不占空间。这样，智能体就能获得详细的指导，而不必在每个上下文窗口中都塞入整本“公司手册”。这些技能经过了版本控制，并针对测试夹具进行了测试，通过标准化的渠道发布，因此流程的变更总是经过深思熟虑后推出的。工程师可以更换工具，但不会丢失公司规划、审查和交付工作的既定方法。这就是一个局部经验转化为公司整体能力的途径。当某个项目找到了更好的架构审查或版本发布验证方法时，这种改进就会被吸纳进相应的技能中，未来的每一次会话都将自动继承这一成果。 ## 开发流程具备机器接口原则 5：单一记录，多维视角。如果没有机器接口，在你的代码库中工作的智能体只能靠读取文件去猜测。Tenex CLI 消除了猜测，并（通过 30 多个命令）实施了安全护栏，这样工程师就不必时刻盯着代码库。智能体询问什么是事实、什么已准备就绪、哪里出了问题以及下一步会发生什么，随后就能获得结构化的事实回复。例如： - 哪些工单的阻塞已解除。 - 项目记录与 Linear 上的信息哪里存在出入。 - 计划中缺失或无效的必需部分有哪些。 - 让 Linear 上的状态与 Markdown 保持一致。 - 批准确认验收标准。每个回答都以“项目记录”为基准，因此智能体绝不会基于过时的事实依据来工作。向 Linear 和 GitHub 写入数据的方式，沿用基础设施工具过去十年的运作模式：在任何操作执行之前，你能看到完整的执行计划，而应用该计划需要一个独立且刻意的步骤。如果一个工单看起来可能与 Linear 上的两个问题相匹配，系统将拒绝执行并指出这两个问题的名字。 Tenex CLI 的价值在于，对 Linear 的写入操作，要么绝对正确，要么根本就不会发生。如果说项目记录是蓝图，那么 CLI 就是将其转化为工作指令，并在 Linear 的状态不再匹配蓝图时触发警报的角色。 ## 校验让“自主”更安全原则 6：让智能体自查工作。智能体必须被套上“缰绳”，因为它们可能极具说服力却错得离谱。因此，信任是通过验证来赢得的。系统会检查计划中是否缺失关联关系，核对工单是否符合验收标准，检查文档是否与代码相一致。这些检查也为智能体提供了一种修复自身工作的方式。运行 `tenex validate` 可能会返回类似这样的提示：“PS-portal 的 6 号工单指向了不存在的里程碑 M3；请重新关联或移除。”这种足够精确的指导能够让智能体进行自我修复并再次运行检查，全程无需人工干预。长时间的任务执行，不再依赖于智能体能否在数小时内维持一条完美无瑕的推理链。最终呈现在工程师面前的，都是智能体无法自我修正的错误。如果一个智能体在没有任何关联的 PR、测试或签字确认的情况下将工单标记为“已完成”，这种虚假声明是绝对无法成立的。 ![Image](/doc/3954/image/img_2b93265f710e.jpg) 当一个智能体具备了以下条件时，它就会变得更有用：拥有理解目标的上下文、采取行动的工具、有边界的权限、可观察的进度标准、持久化的状态，以及清晰的呈报路径。解除这些约束并不会让它变得更自由，只会让它更加不确定，并迫使人类重新介入循环来解决模糊性。我们的目标从来不是追求最大程度的自主。而是要消除对人类注意力的过度依赖，同时让那些真正需要人类介入的时刻变得更容易被捕捉。 ## Tenex OS 让团队对流程一目了然原则 7：状态是推导出来的，而非汇报出来的。同样结构化的状态为 Tenex OS——我们面向人类的交互界面——提供了动力。工程师可以审查最接近构建阶段的工作，工程主管能随时掌握规划和质量风险，而领导层则可以审视所有项目的交付健康状况。一份基于记忆构建的状态报告，往好了说是主观的，往坏了说就是严重失真。当史诗需求、规范、工单、分支和 PR 被相互关联后，系统就能提供可验证的事实来源，并对不一致之处进行标记。如果系统显示某个工单已完成但缺少证据，这种不一致就会立即暴露。一切都在意料之中，没有惊吓。 ![图片](/doc/3954/image/img_83bdaae19ed2.jpg) ## 流程在工作中自我学习原则 8：经验教训为所有人不断复利。每个项目都可以改进用于运行下一个项目的系统。一个反复出现的规划漏洞会转化为一条新的检查规则；一种极其有效的代码库调查方法会沉淀为一项技能；一个持续引发混乱的决策会演变为一条明确的规范；一个需要手动核对的状态同步动作会转化为一条 CLI 命令。传统组织也会学习，但这种学习是通过人员入职培训和团队文化来传播的。而我们提供的新机遇在于，将经验沉淀为代码，从而改变未来每一个相关会话的默认行为，让改进以经过测试的、版本控制变更的形式传递，而不是依赖于每个人是否都听到并记住了那些口头建议。这就是为什么流程本身会成为一项持久的资产。客户依然能拿到软件，而我们的团队在软件开发上会变得越来越出色，因为围绕着工作的这套系统留住了它所学到的一切。 ## 流程对人的期望一个高度自动化的 SDLC，可能会让人误以为“判断”也被自动化了。这简直是大错特错。如果说有什么区别的话，那就是我们要求彼此达到的标准反而在不断攀升。智能体就像游乐场里的哈哈镜。用得好，它们能让优秀的工程师能力倍增；用得不好，它们就会让基本功不扎实的人制造出一堆面条代码和电子垃圾。这套系统只会放大你的判断力，而无法凭空赋予你判断力。我们需要明确一点：工程师的工作性质已经改变了。工程工作如今变得更加高层且具备多线程特性：你需要极其清晰地表达意图和架构，好让众多智能体能够据此行动；你需要敢于挑战更难的问题，因为试错成本已经降低；你需要在时间和 Token 的双重维度上高效地调度一支智能体舰队；同时，在这一切同时发生的过程中，还要防止代码库走向腐化。所以，产出的成果是你负责的。再也不存在“是 Claude 让我这么做的”这种借口。只要你合并了代码、发送了邮件，或将其展示给了利益相关者，你就要对它的正确性负责，而“认真审查你交付的东西”绝非可选项。自己铺的床，自己就得负责去睡。 ## 从何开始你今天就可以在任何代码库中免费开始尝试。它只需要一个项目和几周时间的自律。如果让我们从头来过，我们会按照以下顺序进行。从三个文件夹开始，而不是七个：什么是当前事实、我们打算构建什么、以及发生了什么。将它们以 Markdown 格式放在代码库旁，并克制住在使用之前就想设计一套完美分类法的冲动。第四个文件夹请尽早添加草稿区（scratchpad），这比你预期的要早，因为如果不这样做，人们就会把粗略的笔记写到那些核心文档里。为一个真实的项目编写一份蓝图。写清楚你正在构建什么、为什么重要、主要的边界和决策是什么、接下来的几块工作是什么，以及每块工作在验收前必须满足什么条件。这是发挥作用最大的一份产出物，而且借助智能体，编写它只需要几个小时而非几天。在第一天就采用“栅栏规则”。决定好文档中哪些部分允许机器重写，并将它们标记出来，无论是用代码隔离区、注释标记还是单独的文件。如果你之后再去改造，就意味着你得去拆解每一份已经被同步操作覆盖了人类文字的文档。无论如何，添加哪怕一个小小的校验器。哪怕只是一个脚本，用来标记那些指向不存在里程碑的工单，或者标记自架构改变后就从未被触碰过的文档。仅仅一个检查就足以改变失败的模式：系统状态偏移会立刻产生一个失败的检查警告，而不是在六周后给你一个措手不及的惊吓。给每次会话提供相同的初始数据包。从那些文件中提取组装，这样一来，项目的定位就不再依赖于当天早上是谁写的提示词。同时，从记录中直接推导出项目健康度的一个视图，而不是去要求某个人手动写一份报告。然后，观察哪里会感到吃力。凡是记录缺失、陈旧或错误的地方，就是你目前还在依赖人类记忆来维持运转的流程环节，而你每修复一个，收益就会不断叠加。坦诚地说，这里有两个局限。在低于一定规模时，这套机制是大材小用的：单一项目上的单一团队出现偏差的速度很慢，以至于走这些繁文缛节耗费的成本远大于其带来的收益；只有当并发任务增加时，这种方法才能收回成本。此外，它依赖于一项技术无法提供的投入，那就是“写下事情”。之所以需要校验，是因为仅靠人的自律最终一定会失效；但如果一个团队拒绝写下任何东西，那他们需要优先解决的是另一个截然不同的问题。 ## 到底有何不同传统的权衡将详尽的规划放在天平的一端，将速度放在另一端，因为人类需要手工维护流程的每一个环节。智能体改变了这种权衡。当结构化能消除重复的探索、防止产生不兼容的工作、为每个智能体提供可靠的起点，并让失败更容易被检测和修复时，它就不再是阻力，反而会极大提升速度。真正的实战检验在于：一个新的智能体能否参与到一个项目中，理解预期的系统，选择符合当前计划的工作，加载公司规定的执行方法，证明它所做出的改变，并为下一个智能体留下一个更容易理解的项目？对组织而言的检验则是：工程师和管理者能否无需通过开会和手动更新的仪表盘来拼凑事实真相，就能直接跨项目审查这些工作？如果这两点都成立，那么编程智能体就不仅仅是执行速度更快的码农。它们将成为这个开发系统的真正参与者，使系统能够承担更大的复杂性而不至于迷失方向。与 Tenex 合作无论您是希望将贵公司的 SDLC 重塑为 AI 原生架构的工程负责人，还是试图通过一支前沿部署的精英工程师团队来解决最棘手技术挑战的企业高管，我们都能为您提供支持。加入 Tenex 如果您是一名 AI 原生工程师，渴望站在技术最前沿，为代码库支撑着数十亿美元生意的客户交付生产级 AI 系统，欢迎加入我们的团队。 ## 相关链接 - [Alex Lieberman](https://x.com/businessbarista) - [@businessbarista](https://x.com/businessbarista) - [48K](https://x.com/businessbarista/status/2085383591475773666/analytics) - [@tenex_labs](https://x.com/@tenex_labs) - [@ArmanHezarkhani](https://x.com/@ArmanHezarkhani) - [@dan_zakon](https://x.com/@dan_zakon) - [@seejayhess](https://x.com/@seejayhess) - [https://www.tenex.co/blog/building-an-ai-native-sdlc](https://www.tenex.co/blog/building-an-ai-native-sdlc) - [Agile Manifesto](https://agilemanifesto.org/) - [we can support you](https://www.tenex.co/ai-transformation) - [Join the team](https://www.tenex.co/careers) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [11:12 PM · Aug 6, 2026](https://x.com/businessbarista/status/2085383591475773666) - [48.6K Views](https://x.com/businessbarista/status/2085383591475773666/analytics) - [View quotes](https://x.com/businessbarista/status/2085383591475773666/quotes) --- *导出时间: 2026/8/7 22:01:27*