# Agent Process, Meet Design Process
**作者**: Simon Corry
**日期**: 2026-07-15T18:52:52.000Z
**来源**: [https://x.com/simoncorry/status/2077466446452736161](https://x.com/simoncorry/status/2077466446452736161)
---
If you've been anywhere near a conversation about AI coding agents this year, you've met the words: harness, loop, context window, skills. I've watched genuinely good designers nod along to all four in a meeting and then quietly look up every one of them afterward.
So here's the post I wish someone had written for me. I’m gonna share the plain English version because left to agents this stuff becomes unintelligible fast. Then we’ll talk through how it all this maps neatly onto the design process. Foundry, is essentially an agent process for building. It's small, it's free, and every part of it got beaten into shape by yours truly over months of tears and frustration.
Unfamiliar marks resolving into a readable row.
## The words, in plain English
Let's do the lexicon first. One clear line each, no weird mystique or jargon.
1. An agent is a model with opposable thumbs. Not just chat: it reads your files, runs commands, edits code, and checks its own results. When people say "I had the agent fix it," this is what they mean.
2. A harness is the tool holding the agent: Cursor, Claude Code, Codex, etc. It decides what the agent can touch, shows you what it's doing, and asks (or doesn't ask) before anything risky.
3. The context window is the agent's working memory, everything it can see right now. It's big but finite, and when it fills up, the oldest stuff falls out. Most "the agent isn’t listening to me” stories are really “my request fell out of the context window" stories.
4. A rules file is a markdown file at the root of your project that the agent reads at the start of every session. Most tools read one named AGENTS. It's your standing instructions: what you're building, the commands you run, the corrections you're tired of repeating.
5. A command is a markdown file that becomes a shortcut. Drop a file in the right folder and typing forward slash and then its name in chat runs the whole recipe inside it. This matters more than it sounds, so keep it in mind as you read on.
6. A skill is a folder of reference knowledge the agent pulls in when needed. Think of it as a training manual it reads on demand instead of carrying the context in its head 24/7.
7. A loop is the agent going again without you: finish a turn, check against a condition, start another. The built-in commands that run loops unattended are genuinely impressive, and I'll have more to say about them later.
8. An agent process is the thing we’ve created with Foundry. It’s the steps the agent runs inside its harness that will create meaningfully better results for you.
None of these are hard ideas. It’s just complicated people seem to love gatekeeping, sometimes by accident and sometimes to scare you away. I’m here to tell you that you CAN learn this and to offer you a head start.
Two processes running parallel, connected at every stage.
## The process you already trust
Here's the thing that probably took me way too long to notice or maybe I was just fighting it because I believed it should be different. Designers already have the mental model for all of this, in fact we’ve had it for decades.
You don't start a client project by pushing pixels. You research, you define the problem, you interview the client, you present a direction, you take the crit, you build, you test against the goal, you hand off with documentation. The Double Diamond has been on a whiteboard (or the book) in every studio I've worked in since 2005: understand the problem before you build the thing, and both halves get their own diverge-and-converge paths. The model teaches five stages that every design graduate ends up memorizing. Also it’s focus on critique, the idea that structured crit (with fresh eyes and focus), is the single most valuable ritual our field ever invented.
PSA: If you’re on X raving about your latest design being “fresh” or “clean,” but haven’t had it go through the proper testing and feedback from real users, you’re just adding noise to our timelines. I will mute and/or block you so please post responsibly!
Now back to the lexicon. Think of the rules file as your brand guidelines, they represent standing constraints anyone new to the project reads first. The plan is the brief. The context window is like working with a freelancer, you need to re-brief them at the start of every engagement. A skill is the bookshelf in the corner of the studio. Commands are your studio's named rituals, the things you do the same way every time because that sameness IS your taste.
Okay, so the mapping isn't 100% perfect, but it's close enough that designers should be walking into agent work with a home-field advantage (at the time of writing it’s the World Cup so I snuck a sports analogy in). Mostly we don't feel like we have the advantage though, and in my experience that’s largely because people are yelling at you to adopt AI without understanding wtf they’re talking about.
The gap in the middle of the standard setup.
## What the standard pieces still miss
So you set up the rules file, you write a plan before coding, maybe you even hand the agent a finish line and let a loop run. That's a solid setup. It's also, if I'm being honest about my own observations, still missing the four things that make a real designer's process work.
There's no crit. The agent presents work and you either take it or poke at it yourself, but nothing structurally forces a fresh-eyes review from a declared angle before the work ships. And unstructured "does this look right?" review catches about as much from an agent as it does from a bad designer.
There's no client interview. The agent never sits you down and asks the three questions that would change the whole direction, the way any decent designer does before touching a tool. It just starts making things with whatever you happened to say.
There's no handoff. When your terminal closes, the reasoning evaporates. Every session starts as the new freelancer who's never seen the project, and unless you build the memory yourself, it stays that way forever.
And there's nobody checking whether "done" means "right." A loop that runs until a condition passes. Half my early sessions ended with me nodding at lines of code and just agreeing with the agent conclusion. I could not have explained any of the rationale to another human being. And yes, that’s as bad as it sounds, but it’s also true that many new builders are guilty of following without truly understanding.
Foundry is my answer to those gaps, and the shape of the answer is the same shape design already uses: a process with named stages.
Wide understanding converging toward one settled plan.
## Before the agent writes anything
The first half of the chain is the first diamond: understand and decide, before any code.
A session opens with start-up, which is the agent reading the note the last session left, checking the state of the project, and telling me where things stand. Ten seconds of reading that replaces the half hour of waiting and then the inevitable “oh crap, I didn’t want you to build that”.
Then construct-the-plan. The agent researches the territory and writes a real plan into a real file in the project, split in two: a narrative half in plain language for me, a working half with the precise steps for the agent. Plans are cheap to change; code can be a pain in the ass. Every hour I've spent arguing with a plan has paid for itself ten times over and I’ll happily die on this hill.
Then my favorite stage, the one you might not realize you even need: frame-it. The agent gives me a short brief on the state of our world (what good looks like, what we've already decided, where projects like this go wrong) and then it interviews ME. Three to five questions, biggest consequences first, each with options and a recommendation. It's the client interview, except I'm the client, and the designer asking the sharp questions is the agent. The built-in commands will answer any question you ask of it but not one of them asks you the question you needed to be asked.
Then the crit. Five challenge rounds against the plan, each from a genuinely different declared angle: one walks the sequence of steps, one hunts what the plan added that nobody asked for, one goes outside the codebase to check the plan's claims against reality (I'm confidently wrong more than I'd like), and the last one re-reads everything the earlier rounds flagged as shaky and rules on each item. I wrote about the bug curve in an earlier post, so the short version: when the angles genuinely rotate you find something every round, and when they accidentally repeat you find nothing. Same as a crit where everyone's hunting the same flaw.
One design habit that’s engrained into me and now Foundry, don't let the agent glaze you. Every round edits the plan directly and reports what changed without trying to make me feel superior.
The work under review from five declared angles.
## Making it, and proving it
The second half is the second diamond: build the thing right (measure twice, cut once).
Build-it is the prototype stage, and it's deliberately the quietest command in the chain, because the plan was challenged before it and the work gets reviewed after it. One thing worth stealing (even if you ignore everything else I’m saying), when reality inevitably forces a departure from the plan, the agent shouldn’t stop to grill you (I'm often not there anyway so the chain continues to run while I'm making dinner). For safety it’s trained to take the conservative option and logs the departure in the plan file, then on the next review round it knows to read that log first.
Test-it writes tests against what the plan intended, never against what the code happens to do. This distinction sounds pedantic and it is but it’s also everything. An agent grading its own homework will happily write a test that asserts the bug (ask any engineer worth their salt). Deriving the expected answers from the plan, with concrete values, keeps the test honest. Designers you already know this because you judge the work against the goal, not against your ego.
When the work touches anything sensitive (sign-in, payments, anything that takes input from strangers), a security scan runs: an expert pass against a named checklist of failure classes, where every candidate finding has to argue against itself before it's allowed in the report. In design terms it's heuristic evaluation, and the argue-with-yourself step exists because agents (like juniors) want to look useful and will flag everything.
Then five more rounds, this time against the code. The plan crit was about direction; this is the review that drives the work to shippable. Different default angles (does the same mistake exist anywhere else, did our own fixes break something, do the gaps between pieces actually line up), same rule about genuine rotation, same fix-don’t-glaze policy.
And wrap-up is the state you leave your desk in. Dead code out, notes updated, the one pull request opened, and a plain-English summary of what you have. Not what it did. What you actually have.
Sessions as nodes on one continuous line.
## The trail is the point
The last stage writes the handoff note: what's in flight, what's next, what would be hard to reconstruct cold. Next session's start-up reads it, and the loop closes. That pair, handoff writing and start-up reading, is the entire difference between an agent that's a string of talented freelancers and your ride-or-die work colleague. And the memory is now a real thing in the repo, not vibes: every session leaves one plain-English entry in a running log, and when the log outgrows a week, older entries rotate into dated history files. There's a wiki growing beside it too, one topical page at a time, fed by the same wrap-up stage that cleans your desk. The log is what happened and the wiki is what we know.
Everything the chain touches leaves a trail on purpose. The rules file accumulates corrections. The plans record what we decided and what we rejected. The session notes record what happened. The handoff bridges the gap to tomorrow. When people ask what they actually get from all this ceremony, that trail is the answer: the code is the smallest part of what you're building. The soul of the project, the reasoning, lives in the trail, and the trail is what survives the terminal closing.
The bookshelf grew too. My agent works from four installed libraries: software engineering fundamentals, game development, design, and motion. The last two are the ones a design engineer actually works from, which means my agent cites Dieter Rams at me during reviews now, and honestly? It has recall than I do. Three of those shelves ship inside Foundry's wiki (the game one stays in private collection, for obvious reasons), so your agent gets the same grounding on day one: Brooks and Parnas for the engineering arguments, the Norman-to-Rams canon for the design ones, and the motion material adapted with credit from Emil Kowalski's and Meng To's MIT-licensed work.
There's even an opt-in stage called quiz that tests ME on a change that just shipped and teaches through the grading. Merging code you can't explain is how codebases become dumpster fires; five minutes of getting quizzed is good for the soul and your engineering friends. Don’t skip this part especially if you’re new to programming. You’d be shocked how much you can pick up regarding the engineering fundamentals without needing to write a line of code.
The honest trade: finishing fast on one side, staying right on the other.
## The honest trade
The built-in loop commands are actually pretty good. When Claude Code or Codex runs a goal loop to "done" while you sleep, that's real, and for throwaway work you can and should trust it. Foundry's trade runs the other direction: it optimizes for being right and for you understanding what happened, and it pays for that in tokens and time. The full chain on a mid-size feature costs real money. There's a documented light path (two challenge rounds a side instead of five) that keeps the shape at a fraction of the cost.
The chain has no user-research stage, nothing in it talks to your users and that’s by design. It’s my firm belief that this is where the human touch should be drawing a natural line. This is also not a replacement for divergent sketching. Ten critiques of one design by an agent is not the same thing as ten designs being critiqued by a skilled artisan. Keep humans around you for feedback and critique.
The platforms already let anyone write custom commands. Foundry isn't a capability they lack; it's a considered, working set, with the habits and memory around it, so you don't have to spend the months of trial and error I did. Hopefully this helps some folks on their own journey of discovery.
Start small; the structure grows from one seed.
## Where to start
The repo is at github.com/simoncorry/foundry, MIT licensed. Clone it and start a project inside it, or copy its command folders and rules file into a project you already have; that's the whole install (or simply point your agent at the URL and ask it to determine the best way to set up, it’s built for them to read). The commands are plain markdown, so they work in Cursor, Claude Code, and Codex, and if your tool is something else you can paste a stage straight into the chat. The README carries the reference version of everything this post narrates, so have fun.
You invoke the following build chain by typing each command in and queuing them sequentially. This ensures the agent runs through each with the clear discipline written in the command files:
1. /start-up — reads the branch, working tree, handoff note, and sessions log.
2. /construct-the-plan — writes the two-part plan file into your repo. You can add your own wishlist for the session here or if it’s a continuation the agent will just use the handoff.
3. /frame-it — the agent briefs you and interviews you (3-5 questions). This is your last required moment at the keyboard.
4. /challenge-plan-1 through challenge-plan-5 — five review rounds against the plan, each from a different angle; the fifth re-reads everything earlier rounds parked as uncertain.
5. /build-it — implements the settled plan, logging any departures in the plan file instead of stopping to ask.
6. /test-it — writes tests against what the plan intended and drives them to green.
7. /security-scan — optional, only when the work touches anything sensitive.
8. /challenge-implementation-1 through challenge-implementation-5 — five more rounds, now against the code.
9. /wrap-up — cleans the workspace, grows the jargon list, writes the session log entry, distills to the wiki, opens the one pull request.
10. /handoff — optional, only when you ask: the bridge note for next time.
11. /quiz — optional, when you want to learn about what you built.
If the whole chain feels like too much on day one, ease yourself in. Start with the rules file. Add the handoff-and-start-up pair the first time a session opens with "wait, where were we." Add the interview the first time the agent builds the wrong thing confidently. Add the crit the first time you merge something you couldn't explain. And to be clear that's the order I learned it in.
Designers have spent decades refining a process for doing creative work with other minds. Turns out it works on the artificial ones too. If you can dream, you can build it. I’m here if you need me.
This was originally posted on my blog:
- https://simoncorry.com/blog/2026/07/15/design-process-meet-agent-process
You can also play Tetris & Space Invaders (now with sound!):
- https://simoncorry.com/tetris
- https://simoncorry.com/space-invaders
## 相关链接
- [Simon Corry](https://x.com/simoncorry)
- [@simoncorry](https://x.com/simoncorry)
- [4.2K](https://x.com/simoncorry/status/2077466446452736161/analytics)
- [Foundry](https://github.com/simoncorry/foundry)
- [github.com/simoncorry/foundry](https://github.com/simoncorry/foundry)
- [https://simoncorry.com/blog/2026/07/15/design-process-meet-agent-process](https://simoncorry.com/blog/2026/07/15/design-process-meet-agent-process)
- [https://simoncorry.com/tetris](https://simoncorry.com/tetris)
- [https://simoncorry.com/space-invaders](https://simoncorry.com/space-invaders)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [2:52 AM · Jul 16, 2026](https://x.com/simoncorry/status/2077466446452736161)
- [4,206 Views](https://x.com/simoncorry/status/2077466446452736161/analytics)
- [View quotes](https://x.com/simoncorry/status/2077466446452736161/quotes)
---
*导出时间: 2026/7/16 15:00:25*
---
## 中文翻译
# 智能体流程，遇见设计流程
**作者**: Simon Corry
**日期**: 2026-07-15T18:52:52.000Z
**来源**: [https://x.com/simoncorry/status/2077466446452736161](https://x.com/simoncorry/status/2077466446452736161)
---
如果你今年参加过任何关于 AI 编程智能体的讨论，你一定听过这些词：harness（框架）、loop（循环）、context window（上下文窗口）、skills（技能）。我亲眼见过一些真正优秀的设计师在会议上对这四个词频频点头，然后私下里却一个个去查它们是什么意思。
所以，这是一篇我希望能有人早些写给我的文章。我要分享这些概念的通俗英语版本，因为如果让智能体自己来解释，这些东西很快就会变得晦涩难懂。然后，我们将探讨这一切是如何完美映射到设计流程上的。Foundry 本质上就是一个用于构建的智能体流程。它很小，它是免费的，而且它的每一个部分都经过了我本人数月的眼泪和挫折的锤炼才成型。
陌生的符号逐渐解析成可读的一行行内容。
## 这些词汇，用大白话讲
我们先从词汇表开始。每个概念用一句清晰的话解释，没有玄乎的神秘感，也没有行话。
1. **智能体（Agent）** 是一个拥有“拇指”（意味着具备操作能力）的模型。不仅仅是聊天：它会读取你的文件，运行命令，编辑代码，并检查自己的结果。当人们说“我让智能体修复了它”时，指的就是这个意思。
2. **框架（Harness）** 是承载智能体的工具：Cursor、Claude Code、Codex 等。它决定了智能体能触碰什么，向你展示它在做什么，并在进行任何危险操作前询问（或不询问）你。
3. **上下文窗口（Context Window）** 是智能体的工作记忆，也就是它此刻能看到的所有内容。它很大但有限，当它被填满时，最早的信息就会被挤出去。大多数“智能体不听我的”的故事，其实都是“我的请求掉出了上下文窗口”的故事。
4. **规则文件（Rules file）** 是位于项目根目录的一个 Markdown 文件，智能体在每次会话开始时都会读取它。大多数工具会读取一个名为 AGENTS 的文件。这是你的常备指令：你在构建什么，你运行的命令，以及那些你已经厌倦了重复的纠正。
5. **命令（Command）** 是一个变成快捷方式的 Markdown 文件。把文件丢进正确的文件夹，然后在聊天中输入斜杠和它的名字，就能运行里面的整个脚本。这比听起来更重要，所以请在阅读时牢记这一点。
6. **技能（Skill）** 是一个包含参考知识的文件夹，智能体会在需要时调用它。把它想象成一本按需阅读的培训手册，而不是让智能体没日没夜地把所有信息都装在脑子里。
7. **循环（Loop）** 是智能体在没有你参与的情况下再次运行：完成一轮，对照条件检查，开始新的一轮。那些无人值守运行的内置循环命令确实令人印象深刻，我稍后会多谈谈它们。
8. **智能体流程（Agent process）** 是我们用 Foundry 创造出来的东西。它是智能体在其框架内运行的步骤，这些步骤能为你带来真正更好的结果。
这些概念都不难懂。只是有些喜欢故弄玄虚的人似乎总想设置门槛，有时是偶然的，有时是为了吓退你。我在这里告诉你，你**能**学会这些，并愿助你一臂之力。
两个流程并行运行，在每个阶段都相互连接。
## 你早已信任的流程
这件事可能我花了太长时间才意识到，或者也许我一直在抗拒，因为我本以为它应该有所不同。设计师其实早已拥有这一切的心智模型，事实上，我们已经拥有它几十年了。
你不会一开始就通过推像素来开始一个客户项目。你会做调研，定义问题，采访客户，提出方向，接受评审，构建，对照目标进行测试，最后通过文档进行交付。自 2005 年以来，我在每个工作过的工作室里都能在白板（或书）上看到“双钻模型”（Double Diamond）：在构建之前先理解问题，两个半程都有各自的“发散-收敛”路径。该模型教授了五个阶段，每个设计毕业生最终都会背下来。此外，它强调评审，即结构化的评审（拥有新鲜的视角和专注力），是我们领域发明过的最有价值的仪式。
公告：如果你在 X 上吹嘘你的最新设计是“新颖的”或“干净的”，但却没有让它经过真实用户的适当测试和反馈，那你只是在我们的时间线上制造噪音。我会屏蔽和/或拉黑你，所以请负责任地发布！
现在回到词汇表。把规则文件想象成你的品牌指南，它们代表了任何刚接触该项目的人都会首先阅读的固定约束。计划就是简报。上下文窗口就像与自由职业者合作，你需要在每次合作开始时重新向他们简报。技能是工作室角落里的书架。命令是你工作室既定的仪式，那些你每次都以相同方式做的事情，因为这种一致性**就是**你的品味。
好吧，虽然这种映射不是 100% 完美，但已经足够接近，设计师们进入智能体工作领域时应该拥有主场优势（在撰写本文时正值世界杯，所以我偷偷用了一个体育类比）。不过，大多数时候我们并没有觉得自己有优势，根据我的经验，这很大程度上是因为人们在都不明白自己在说什么的情况下，却冲着你大喊大叫让你接受 AI。
标准设置中间的缺失环节。
## 标准组件仍然缺失的部分
所以你设置好了规则文件，在编码前写好了计划，甚至可能给智能体设定了终点并让循环运行。这是一个很棒的设置。但是，如果诚实地谈谈我自己的观察，它仍然缺少了四个让真正的设计流程奏效的关键要素。
**没有评审（Crit）。** 智能体展示工作成果，你要么接受，要么自己挑刺，但在成果发布前，没有任何结构化的机制强制从特定角度进行“新鲜视角”的审查。而且，非结构化的“这看起来对吗？”审查，对于智能体来说，能发现的问题并不比从一个糟糕的设计师那里能发现的多。
**没有客户访谈。** 智能体从未坐下来问你那三个会改变整个方向的问题，而任何像样的设计师在使用工具前都会这么做。它只是开始根据你随口说出的东西制作东西。
**没有交付。** 当你的终端关闭时，推理过程就蒸发了。每次会话都像是一个从未见过该项目的新自由职业者重新开始，除非你自己构建记忆，否则它永远都会是那样。
**没有人检查“完成”是否意味着“正确”。** 一个循环运行直到条件通过。我早期的一半会话结束时，我都对着几行代码点头，只是附和智能体的结论。我无法向另一个人解释其中的任何基本原理。是的，听起来这很糟糕，但这同样是事实，许多新的构建者往往都有盲目跟随而不真正理解的毛病。
Foundry 是我对这些缺失环节的回答，而这个回答的形状与设计已经使用的形状相同：一个具有命名阶段的流程。
从宽泛的理解收敛为一个确定的计划。
## 在智能体写出任何东西之前
链条的前半部分是第一颗钻石：在任何代码编写之前，先理解和决策。
一个会话以**启动**开始，这是智能体读取上次会话留下的笔记，检查项目状态，并告诉我目前的进展。阅读它花费的十秒钟，取代了半小时的等待，以及随后不可避免的“哦，该死，我并不是让你构建那个”。
然后是**构建计划**。智能体调研该领域，并将一个真正的计划写入项目中的一个真实文件，分为两部分：一部分是用通俗语言写给我的叙述性内容，另一部分是包含精确步骤的供智能体执行的工作内容。修改计划很廉价；修改代码则可能是个麻烦。我在争论计划上花费的每一个小时，都得到了十倍的回报，我愿意为此据理力争。
接下来是我最喜欢的阶段，你可能都没意识到自己需要它：**界定框架**。智能体给我一个关于我们世界现状的简报（什么是好的，我们已经决定了什么，类似的项目通常在哪里出错），然后它采访**我**。三到五个问题，后果最严重的排在最前，每个问题都有选项和建议。这就是客户访谈，只不过我是客户，而提出尖锐问题的设计师是智能体。内置命令会回答你问它的任何问题，但没有一个会问你那个你需要被问到的关键问题。
然后是**评审**。针对计划的五轮挑战，每一轮都来自一个真正不同的特定角度：一轮按步骤顺序检查，一轮寻找计划中添加的但没人要求的内容，一轮跳出代码库检查计划的主张是否符合现实（我对自己过于自信的错误比我愿意承认的要多），最后一轮重读早期轮次标记为不稳的内容并对每一项进行裁决。我在之前的文章中写过关于“Bug 曲线”的内容，所以简而言之：当角度真正轮换时，你每轮都能发现问题；当它们意外重复时，你什么也发现不了。这就像评审中每个人都在寻找同一个缺陷一样。
有一个已经融入我（现在也融入 Foundry）的设计习惯：**不要让智能体糊弄你**。每一轮都直接编辑计划并报告更改了什么，而不试图让我觉得自己高人一等。
从五个特定角度审查工作成果。
## 构建与验证
后半部分是第二颗钻石：正确地构建事物（三思而后行）。
**构建** 是原型阶段，它被特意设计为链条中最安静的命令，因为计划在此之前已经受到挑战，而工作在此之后会受到审查。有一点值得借鉴（即使你忽略我说的其他所有内容），当现实不可避免地迫使偏离计划时，智能体不应该停下来盘问你（反正我经常不在场，所以当我在做晚饭时链条继续运行）。为了安全起见，它被训练采取保守选项并在计划文件中记录偏离，然后在下一轮审查中它知道要先读取该日志。
**测试** 针对计划的意图编写测试，而不是针对代码碰巧做的事情编写测试。这种区别听起来很迂腐，确实如此，但它也是一切。一个给自己的作业打分的智能体会很乐意编写一个断言 bug 的测试（去问问任何值得称道的工程师）。从计划中推导出带有具体值的预期答案，能让测试保持诚实。设计师们你们已经知道这一点，因为你们是根据目标而不是根据自我来评判工作的。
当工作触及任何敏感内容（登录、支付、任何接收陌生人输入的东西）时，会运行安全扫描：针对已知的失败类别清单进行的专家级检查，每个候选发现必须在被允许进入报告之前与自我进行辩论。用设计术语来说，这就是启发式评估，而“与自己辩论”这一步骤的存在是因为智能体（像初级员工一样）想显得有用，会把所有东西都标记出来。
然后是另外五轮，这次是针对代码。计划评审是关于方向的；而这轮审查是将工作推向可交付状态。不同的默认角度（同样的错误是否存在于其他地方，我们自己的修复是否破坏了什么，各部分之间的缺口是否真的对齐），同样的关于真正轮换的规则，同样的“修复问题，不要糊弄”政策。
**收尾** 是你离开办公桌时的状态。清除死代码，更新笔记，打开一个拉取请求，并用通俗英语总结你拥有的东西。不是它做了什么。而是你实际拥有的东西。
会话作为一条连续线上的节点。
## 记录轨迹才是关键
最后一个阶段编写交付笔记：正在进行什么，下一步是什么，冷启动时哪些东西难以重建。下一次会话的启动会读取它，循环闭合。这一对，交付笔记的编写和启动时的读取，是让智能体从一个“有才华的自由职业者串链”变成你“生死与共的工作同事”的全部区别。而且现在记忆是仓库里真实存在的东西，而不是某种氛围：每次会话都在一个运行日志中留下一条通俗英语的条目，当日志超过一周时，较旧的条目会轮换到有日期的历史文件中。旁边也在增长一个维基，一次一个主题页面，由同样清理你桌面的收尾阶段提供内容。日志记录了发生了什么，维基记录了我们要知道的。
链条触及的每一样东西都会故意留下轨迹。规则文件积累纠正措施。计划记录了我们决定和拒绝的内容。会话笔记记录了发生的事情。交付笔记架起了通往明天的桥梁。当人们问他们从所有这些仪式中实际得到了什么时，那条轨迹就是答案：代码只是你正在构建的最小的一部分。项目的灵魂，即推理过程，存在于轨迹中，而轨迹是终端关闭后幸存下来的东西。
书架也增长了。我的智能体从四个已安装的库中工作：软件工程基础、游戏开发、设计和动效。后两个是设计工程师实际工作的来源，这意味着我的智能体现在在评审时会引用迪特·拉姆斯的话，老实说？它的记忆力比我好。这三个书架随 Foundry 的维基一起提供（游戏开发那个留在私人收藏中，原因显而易见），所以你的智能体在第一天就能获得同样的基础：工程论证方面有 Brooks 和 Parnas，设计论证方面有从诺曼到拉姆斯的经典，以及改编自 Emil Kowalski 和 Meng To 的 MIT 许可作品的动效材料。
甚至还有一个可选的**测验** 阶段，它会就刚刚发布的变更测试**我**，并通过评分进行教学。合并不懂的代码是代码库变成垃圾场的原因；五分钟的测验对灵魂和你的工程师朋友都有好处。不要跳过这一部分，特别是如果你刚接触编程。你会震惊于无需编写一行代码就能在工程基础知识方面掌握多少。
诚实的权衡：一边快速完成，一边保持正确。
## 诚实的权衡
内置的循环命令其实相当不错。当 Claude Code 或 Codex 在你睡觉时运行目标循环直到“完成”，这是真实的，对于一次性工作，你可以而且应该信任它。Foundry 的权衡则朝另一个方向发展：它优先考虑正确性以及你对发生的事情的理解，并为此付出 Token 和时间的代价。在一个中型功能上运行完整的链条需要真金白银。有一个文档化的轻量级路径（每边两个挑战轮，而不是五个），以一小部分成本保持相同的结构。
该链条没有用户研究阶段，它里面的任何内容都不会与你的用户对话，这是有意为之。我坚信这是人类应该划出自然界限的地方。这也不是发散性草图绘制的替代品。由智能体对一个设计进行十次评审，并不等同于一个熟练的工匠评审十个设计。在身边保留人类以获取反馈和评审。
这些平台已经允许任何人编写自定义命令。Foundry 不是它们缺乏的能力；它是一个经过深思熟虑的、可工作的组合，带有围绕它的习惯和记忆，这样你就不必像我一样花费数月的试错。希望这能帮助一些人在他们自己的探索旅程中。
从小处开始；结构从一个种子生长出来。
## 从哪里开始
仓库位于 github.com/simoncorry/foundry，采用 MIT 许可证。克隆它并在其中启动一个项目，或者将其命令文件夹和规则文件复制到你已有的项目中；这就是整个安装过程（