Translations: Korean by DG Hong译文：韩语版由 DG Hong 翻译

How can we work effectively with AI? What’s the workflow, how does it scale, and how do we improve our systems over time? And ideally, it should compound. Every finished artifact—code, docs, analysis, decisions—becomes context for the next session. And each correction updates a config that reduces future errors. While I’m still learning, I’ve repeated my answers often enough that I’m writing it here so the next time I’m asked I can share a link instead.我们该如何与 AI 高效协作？工作流是怎样的？如何扩展规模？又该如何随着时间推移不断优化我们的系统？理想情况下，这些工作应当产生复利效应。每一个完成的工件——无论是代码、文档、分析还是决策——都应成为下一次会话的上下文。每一次修正都应更新配置，从而减少未来的错误。虽然我仍在学习中，但我已经重复回答过足够多次同样的问题，因此我将其写在这里，以便下次再有人问起时，我可以直接分享链接。

If you use AI regularly, you likely already apply many of these practices. Nonetheless, I believe the underlying principles apply broadly: provide good context, encode your taste as config, make verification easy, delegate bigger tasks, and close the loop. If a practice does not fit, adapt the principle and invent your own. Also notice, as you read, that none of this is specific to AI. It’s simply how you onboard and work with any new collaborator.如果你经常使用 AI，很可能已经应用了其中许多实践。尽管如此，我相信其底层原则是通用的：提供良好的上下文、将你的偏好编码为配置、简化验证流程、委派更重要的任务，并形成闭环。如果某种实践不适用，请根据原则进行调整并创造你自己的方法。另外，在阅读时请注意，这些内容并非 AI 所特有。这实际上就是你引导和协作任何新伙伴的方式。

• • •• • •

Context as infrastructure将上下文视为基础设施

Help models nagivate your context. For example, all my code lives in ~/src and all my knowledge work lives in ~/vault (organized into projects/, notes/, kb/ and so on). When our work is organized, it makes it easier for the model to retrieve context using grep or glob. And by having a clean directory tree, it’s more straightforward to navigate the directory, and find and lean on prior code, project docs, analysis, etc. to improve the work being done.帮助模型导航你的上下文。例如，我所有的代码都存放在 ~/src 中，所有的知识工作都存放在 ~/vault 中（组织为 projects/、notes/、kb/ 等）。当工作井井有条时，模型就能更轻松地通过 grep 或 glob 检索上下文。通过保持清晰的目录树，导航目录、查找并借鉴过往的代码、项目文档、分析等来改进当前工作会变得更加直观。

Connect models to your organization’s context. Models can benefit from organizational knowledge which likely lives in Slack, Drive, Mail, etc. Most have MCPs for Claude Code, Cowork, Claude.ai. On top of these, I also maintain a INDEX.md per project. It’s an annotated index of the relevant docs and channels, and each entry includes the URL, owner, and a brief paragraph explaining what’s inside and when to read it. The annotation helps a lot. A bare list of URLs forces the model to open every link to figure out what’s relevant, wasting time and context. By annotating upfront, we do the heavy lifting once and store it in the index.将模型连接到你组织的上下文中。模型可以受益于组织知识，这些知识通常存在于 Slack、Drive、邮件等平台中。大多数平台都有适用于 Claude Code、Cowork 和 Claude.ai 的 MCP。除此之外，我还为每个项目维护了一个 INDEX.md。这是一个带注释的相关文档和频道索引，每个条目都包含 URL、所有者以及一段简短的说明，解释其内容及阅读时机。注释非常有帮助。如果只是一堆原始 URL，模型必须打开每个链接才能确定相关性，这会浪费时间和上下文。通过预先注释，我们只需一次性完成繁重的工作，并将其存储在索引中。

Onboard each new session like a new hire. With each new session, the model starts with a blank slate. Thus, it helps to treat the per-project CLAUDE.md like the onboarding doc we’d hand to a new teammate on day one. Claude scanned my per-project CLAUDE.md files and highlighted that they included glossaries for acronyms, project code names, and teammates with the same first name. I also have a suggested reading order in the CLAUDE.md, like telling the model to skim INDEX.md first, then TODOS.md, and finally specific topic notes.像对待新员工一样引导每一次新会话。在每次新会话中，模型都是从零开始的。因此，像对待入职第一天的新同事一样，使用项目级的 CLAUDE.md 文档会很有帮助。Claude 扫描了我的项目级 CLAUDE.md 文件，并指出其中包含了缩写词汇表、项目代号以及同名团队成员的说明。我还在 CLAUDE.md 中建议了阅读顺序，例如告诉模型先浏览 INDEX.md，然后是 TODOS.md，最后才是特定的主题笔记。

Build your memory layer. By default, models don’t remember what happened in the last session, so anything worth persisting should be written to disk. I split my memory layer into two buckets. ~/vault holds facts such as project state, artifacts, and domain knowledge; ~/.claude (along with its CLAUDE.md, skills/, guides/) contains my preferences, workflows, and personal taste. The former provides context while the latter provides configuration.构建你的记忆层。默认情况下，模型不记得上一次会话发生了什么，因此任何值得保留的内容都应该写入磁盘。我将记忆层分为两部分：~/vault 存储事实，例如项目状态、工件和领域知识；~/.claude（连同其 CLAUDE.md、skills/、guides/）包含我的偏好、工作流和个人品味。前者提供上下文，后者提供配置。

Taste as configuration将品味转化为配置

Start with ~/.claude/CLAUDE.md. Claude reads this at the start of every session. I think of it as a behavioral contract. My CLAUDE.md contains preferences like how direct to be, when to push back, how to handle mistakes, what to teach me, etc. Here’s a trimmed version:从 ~/.claude/CLAUDE.md 开始。Claude 会在每次会话开始时读取它。我将其视为一种行为契约。我的 CLAUDE.md 包含诸如沟通直接程度、何时提出异议、如何处理错误、教我什么等偏好。以下是一个精简版本：

<behavior>
- Be direct and push back when you disagree; if my approach has problems, say so.
- When unsure about something, say you're unsure rather than guessing confidently.
- When something fails, investigate the root cause before retrying.
- Keep diffs scoped to the task: no drive-by reformats or unrelated refactors.
...
</behavior>

<teaching>
I'm always picking up new systems and domains. When a key term surfaces that I 
likely haven't internalized, explain it in 1-2 sentences and then move on. Format:

> 💡 followed by 1 - 2 sentence explanation
...
</teaching>

Scope it by directory: global, then repo, then project. Put preferences that apply everywhere (e.g., behavior, long-term goals, teaching) in ~/.claude/CLAUDE.md. Put conventions for a specific a repo (e.g., linting, naming, pull requests) in the repo’s root. Put project-specific context (i.e., directory layout, domain knowledge) in the project directory. When you start Claude Code in a subdirectory, it walks up the tree and loads each CLAUDE.md. And when the model navigates into a subdirectory mid-session, the model picks up that directory’s CLAUDE.md too. More in the docs.按目录划分范围：全局、仓库、项目。将适用于所有地方的偏好（如行为、长期目标、教学）放在 ~/.claude/CLAUDE.md 中。将特定仓库的约定（如 linting、命名、拉取请求）放在仓库根目录中。将项目特定的上下文（即目录布局、领域知识）放在项目目录中。当你从子目录启动 Claude Code 时，它会向上遍历目录树并加载每个 CLAUDE.md。当模型在会话中进入子目录时，它也会加载该目录的 CLAUDE.md。更多信息请参阅文档。

When CLAUDE.md gets too long, split it out. A long CLAUDE.md can become a context tax. It loads everything every session even if the session doesn’t need it. To fix this, refactor chunks into guides that load lazily. Don’t @import them (because that just inlines them). Instead, tell your CLAUDE.md to read them when relevant. This way, a session that’s building evals skips the guide on writing docs. Here’s an example guide section:当 CLAUDE.md 变得过长时，将其拆分。过长的 CLAUDE.md 会成为“上下文税”。它在每次会话中都会加载所有内容，即使会话并不需要。为了解决这个问题，可以将部分内容重构为按需加载的指南。不要使用 @import（因为那只是内联），而是告诉你的 CLAUDE.md 在相关时读取它们。这样，一个构建评估（evals）的会话就会跳过关于编写文档的指南。这是一个指南部分的示例：

<guides>
- Docs, 1-pagers, any writing: ~/.claude/guides/writing.md
- Eval building and reports: ~/.claude/guides/evals.md
- Dashboards: ~/.claude/guides/dashboards.md
...
</guides>

If you do something ≥ once a week, make it a skill. A skill is a markdown file with a name, trigger, and procedure that the model loads on demand. Think of skills as workflows written in markdown. They can include logic. For example, my /polish skill looks at the artifact diff. If it produces a metric, it runs the associated eval. If it renders in a browser, it checks the output via Claude in Chrome. If neither, it runs the code and reads the output or error. Skills encode both the steps and the judgment of which steps apply. A few I have include:如果你每周至少做一次某项任务，就把它变成一项技能（skill）。技能是一个包含名称、触发器和过程的 Markdown 文件，模型会按需加载。可以将技能视为用 Markdown 编写的工作流。它们可以包含逻辑。例如，我的 /polish 技能会查看工件差异。如果它产生指标，就运行相关的评估；如果它在浏览器中渲染，就通过 Chrome 中的 Claude 检查输出；如果两者都不是，就运行代码并读取输出或错误。技能既编码了步骤，也编码了判断哪些步骤适用的逻辑。我的一些技能包括：

• /polish: checks for bugs, simplifies the code, verify the output (via evals, Claude in Chrome, or something else), iterate until no critical feedback, draft the PR/polish：检查错误、简化代码、验证输出（通过评估、Chrome 中的 Claude 或其他方式）、迭代直到没有关键反馈、起草 PR
• /write: interviews me for the outline, spawn research subagents, writes the draft, gives feedback via adversarial critic, iterate until no critical feedback/write：采访我以获取大纲、生成研究子代理、编写草稿、通过对抗性批评提供反馈、迭代直到没有关键反馈
• /daily: reads my calendar, slack, PRs, yesterday’s log, etc and writes today’s priorities/daily：读取我的日历、Slack、PR、昨天的日志等，并编写今日优先级

I tend to keep SKILL.md small and focused on the workflow and routing. The knowledge, like templates and scripts, are separate files that the model reads and runs only when needed, just like lazy-loaded guides.我倾向于保持 SKILL.md 小巧，专注于工作流和路由。知识内容（如模板和脚本）是独立的文件，模型仅在需要时才读取和运行，就像懒加载的指南一样。

Bootstrap skills by doing the task once and then asking the model to make it a skill. This is how I build most skills. First, I do the task once, interactively, in a normal session. Then, I ask the model to turn what we just did into a skill. Next, I run the skill on the same or similar task. Inevitably, I’ll need to correct the output, which I do in the same session so feedback is logged in the session transcript. Finally, I ask the model to update the skill based on the corrections and feedback. You can also seed a skill with exapmles of the desired output. Ask the model to extract the patterns, like how you organize your code, or the structure and tone of your docs.通过先手动执行一次任务，然后要求模型将其转化为技能来引导技能构建。这是我构建大多数技能的方法。首先，我在正常的会话中交互式地执行一次任务。然后，我要求模型将我们刚才所做的转化为技能。接下来，我在相同或类似的任务上运行该技能。不可避免地，我需要纠正输出，我会在同一会话中进行纠正，以便反馈被记录在会话记录中。最后，我要求模型根据这些纠正和反馈更新技能。你也可以用期望输出的示例来初始化技能。要求模型提取模式，例如你组织代码的方式，或者文档的结构和语气。

Refine skills via the transcript, not the file directly. The first version of the skill rarely works perfect because it overfits the original session. This is normal. When you run it and need to update the output, correct it within the session. Try not to open and edit SKILL.md directly. Providing feedback in the session gives the model before-and-after pairs which accumulate in the transcript—here’s what we did, here’s what I wanted, and why. Once the output is right, ask the model to merge the feedback into the skill. After a few rounds, the skill converges and you barely have to edit the final output.通过会话记录而非直接修改文件来优化技能。技能的第一个版本很少能完美工作，因为它过度拟合了原始会话。这是正常的。当你运行它并需要更新输出时，在会话中进行纠正。尽量不要直接打开并编辑 SKILL.md。在会话中提供反馈能为模型提供“前后对比”对，这些内容会累积在记录中——我们做了什么、我想要什么以及原因。一旦输出正确，要求模型将反馈合并到技能中。经过几轮迭代，技能就会收敛，你几乎不需要再编辑最终输出。

Nonetheless, not every task needs this context. For brainstorming, exploration, and rough drafts, I enjoy using simple mode (CLAUDE_CODE_SIMPLE=1 claude). Here, CLAUDE.md still loads but the agentic harness—hooks, skills, tool-heavy loops—doesn’t. This gets me closer to the model, which is what I want when I’m thinking out loud rather than shipping.尽管如此，并非每个任务都需要这种上下文。对于头脑风暴、探索和草稿，我喜欢使用简单模式（CLAUDE_CODE_SIMPLE=1 claude）。在这种模式下，CLAUDE.md 仍然加载，但代理框架（钩子、技能、工具密集型循环）不会运行。这让我更接近模型本身，这正是我在进行思考而非交付产品时所需要的。

Verification for autonomy为了自主性的验证

Shift verification left; catch errors at write time. I think of verification as a ladder. The bottom is cheap and deterministic; the top is expensive and requires judgement. We want to address issues at the lowest possible rung. Near the bottom are post-edit hooks that run ruff format, ruff check --fix on files the model just updated. This happens deterministically and doesn’t cost tokens. Higher on the ladder are tests, evals, LLM reviews, etc.将验证左移；在编写时捕获错误。我将验证视为梯子。底部是廉价且确定性的，顶部是昂贵且需要判断的。我们希望在尽可能低的层级解决问题。梯子底部附近是后编辑钩子，它们在模型刚刚更新的文件上运行 ruff format 和 ruff check --fix。这是确定性发生的，不消耗 Token。梯子更高处是测试、评估、LLM 审查等。

Make it easy for the model to verify the work. Give the model feedback loops to improve its output. If the system produces a metric, let the model run the eval and optimize it. If the output renders in a browser, let the model inspect it via Claude in Chrome. If neither, let the model run it and read the error. For example, when building Docker images, I let the model build, read the error, edit the Dockerfile, and rebuild. If I’m tuning a harness, the model runs evals, reads the transcripts, and fixes failures. When building a dashboard, the model checks in Chrome that tooltips render, labels don’t overlap, and the narrative matches the numbers.让模型能够轻松验证工作。给模型提供反馈循环以改进其输出。如果系统产生指标，让模型运行评估并优化它。如果输出在浏览器中渲染，让模型通过 Chrome 中的 Claude 检查它。如果两者都不是，让模型运行它并读取错误。例如，在构建 Docker 镜像时，我让模型构建、读取错误、编辑 Dockerfile 并重新构建。如果我正在调整框架，模型会运行评估、读取记录并修复失败。在构建仪表板时，模型会在 Chrome 中检查工具提示是否渲染、标签是否重叠以及叙述是否与数字匹配。

For long-running tasks, have models watch models. Long sessions can drift as errors build up. One fix is to run a secondary session with fresh context to read the original spec and the recent turns of the primary session. My minimal setup uses two tmux panes, one for the primary dev, one for the pair programmer. Initial instructions and follow-up prompts are appended to a shared file. Periodically, the pair programmer spins up, checks the spec against the primary’s recent transcript, and if something’s off, provides feedback to course correct.对于长时间运行的任务，让模型监控模型。长时间的会话可能会随着错误的积累而偏离。一种解决方法是运行一个带有新鲜上下文的辅助会话，读取原始规范和主要会话最近的轮次。我的最小化设置使用两个 tmux 窗格，一个用于主要开发，一个用于结对编程。初始指令和后续提示会被附加到一个共享文件中。定期地，结对编程模型会启动，根据主要会话的最新记录检查规范，如果发现偏差，则提供反馈以纠正航向。

We can do this in various ways. For example, the pair programmer can watch for execution drift—is the model doing the task right? This is local and tactical, like ignoring an error, reporting a bad metric, or diverging from the spec. There’s also direction drift—is the model doing the right task? These are bigger picture and strategic, and occur when the model misinterprets the original intent and spends hours building the wrong thing. Check for execution drift often and direction drift occasionally.我们可以通过多种方式做到这一点。例如，结对编程模型可以监控“执行漂移”——模型是否正确执行了任务？这是局部且战术性的，比如忽略了错误、报告了错误的指标或偏离了规范。还有“方向漂移”——模型是否在做正确的任务？这是更大局且战略性的，发生在模型误解了原始意图并花费数小时构建错误的东西时。应经常检查执行漂移，偶尔检查方向漂移。

Scaling via delegation通过委派实现扩展

Delegate increasingly bigger chunks of work. Sometimes, we pair-program with models: short tasks, fast feedback, staying in the loop. This well works for fast iterations, exploratory analysis, and prototyping. But with increasingly stronger models, we should aim to delegate bigger tasks. Explain your intent, constraints, and success criteria upfront, then let the model work. You can’t delegate what you can’t verify, so this requires first defining success criteria and metrics. The shift is from giving instructions, one at a time, to fleshing out plans and letting the model execute them end to end:委派越来越大的工作块。有时，我们与模型结对编程：处理简短任务、快速反馈、保持在循环中。这非常适合快速迭代、探索性分析和原型设计。但随着模型越来越强大，我们应该旨在委派更大的任务。预先解释你的意图、约束和成功标准，然后让模型工作。你无法委派你无法验证的任务，因此这首先需要定义成功标准和指标。转变在于从一次给出一个指令，变为充实计划并让模型端到端地执行它们：

“Given these eval suites, build isolated containers per suite and smoke-test that each builds. Then, do the full run, log the eval metrics and transcripts, and use subagents to read the transcripts and confirm the evals ran correctly. Run each eval n times for confidence intervals. Finally, generate the report, verify it follows the report guide, and slack me the results and report URL.”“基于这些评估套件，为每个套件构建隔离的容器，并冒烟测试每个容器是否能构建。然后，执行完整运行，记录评估指标和记录，并使用子代理读取记录以确认评估运行正确。每次评估运行 n 次以获得置信区间。最后，生成报告，验证其是否遵循报告指南，并将结果和报告 URL 发送给我。”

Run sessions in parallel and find the bottleneck. Delegating bigger tasks means we can run more at once. Claude says I typically run three to six sessions simultaneously. The bottleneck has shifted from doing the work to writing clear specs and reviewing outputs fast enough to keep the pipeline moving—the middle is hollowing out. If parallel sessions share a repo, use git worktrees so each session gets its own checkout and don’t overwrite each other’s changes.并行运行会话并寻找瓶颈。委派更大的任务意味着我们可以同时运行更多任务。Claude 说我通常同时运行三到六个会话。瓶颈已经从执行工作转移到了编写清晰的规范和快速审查输出以保持流水线运行上——中间环节正在被掏空。如果并行会话共享一个仓库，请使用 git worktrees，这样每个会话都有自己的检出，不会覆盖彼此的更改。

Make sessions easy to observe. When running multiple sessions, I need to know their state and which one needs attention. On my mac, a stop hook plays a sound when a session finishes (example below). My tmux window titles use a status emoji (⏳ working; 🟢 complete) and a short Haiku-generated label so I know what each pane is doing. The Claude Code status line shows context usage and the current mode. Together, the stop-hook sound signals a finished task, the tmux titles shows which one, and the status line provides the details.让会话易于观察。运行多个会话时，我需要知道它们的状态以及哪个需要关注。在我的 Mac 上，停止钩子会在会话完成时播放声音（示例如下）。我的 tmux 窗口标题使用状态表情符号（⏳ 工作中；🟢 完成）和一个简短的 Haiku 生成的标签，以便我知道每个窗格在做什么。Claude Code 状态行显示上下文使用情况和当前模式。总之，停止钩子的声音提示任务完成，tmux 标题显示是哪个任务，状态行提供详细信息。

# Example stop hook alert
"Stop": [
    {
    "hooks": [
        {
        "type": "command",
        "command": "if command -v afplay >/dev/null 2>&1; then afplay -v 1.0 /System/Library/Sounds/Glass.aiff; else tput bel; fi"
        }
    ]
}

You can check in even if AFK. /remote-control in Claude Code makes this easy. While commuting or waiting in line, I open the code tab in the Claude app to see what’s running and what’s blocked, and if needed, unblock a stalled session with additional context or new instructions. This keeps sessions moving instead of sitting idle for hours. Only do this if there’s something urgent though, not when you’re trying to be present or touch grass.即使不在电脑前也可以查看。Claude Code 中的 /remote-control 使此操作变得简单。在通勤或排队时，我会在 Claude 应用中打开代码标签页，查看正在运行的内容和被阻塞的内容，并在必要时通过附加的上下文或新指令解除阻塞。这使会话保持运行，而不是闲置数小时。不过，仅在紧急情况下这样做，而不是在你试图享受生活或远离屏幕时。

Closing the loop形成闭环

Keep the context rich by working in the open. When we do our work in shared docs, repos, and channels, it makes it easier for everyone—including models—to retrieve and benefit from the context. What we share today becomes part of the org context tomorrow. Try this simple test: could a new teammate replicate your work from last week using only the shared context? If yes, you’re contributing well to the org context; if not, that precious context is stuck in your head. I automate this somewhat via instructions in my CLAUDE.md to post short updates in a worklog channel whenever I finish a substantial task, with links to the artifact PR or doc.通过公开工作来保持上下文丰富。当我们共享文档、仓库和频道中工作时，每个人（包括模型）都能更容易地检索并受益于上下文。我们今天分享的内容明天将成为组织上下文的一部分。试试这个简单的测试：一位新同事能否仅使用共享上下文重现你上周的工作？如果可以，你就在为组织上下文做出很好的贡献；如果不行，那些宝贵的上下文就困在你的脑子里了。我通过在 CLAUDE.md 中设置指令来自动化这一过程，即每当我完成一项重要任务时，就在工作日志频道发布简短更新，并附上工件 PR 或文档的链接。

Mine your transcripts for config updates. Have the model read past session transcripts to find gaps. When I scanned ~2,500 of my past user turns, a sizable percentage contained phrases like “can you also…“, “did you check…“, “still wrong”, etc. These suggest that the model should have done something unprompted, and I should update the CLAUDE.md or skill, or that a verification step is missing or broken. Hit counts show how often a correction happens and the transcripts show exactly what failed. This is why I make corrections within the session, so I can use the transcript as input for my next CLAUDE.md or skills update.从会话记录中挖掘配置更新。让模型读取过去的会话记录以发现差距。当我扫描了约 2,500 条过去的用户输入时，很大一部分包含诸如“你能也……”、“你检查过……吗”、“仍然错误”等短语。这些表明模型本应在没有提示的情况下完成某些操作，我应该更新 CLAUDE.md 或技能，或者某个验证步骤缺失或损坏。命中计数显示了纠正发生的频率，记录显示了失败的具体原因。这就是为什么我在会话中进行纠正，以便我可以使用记录作为我下一次 CLAUDE.md 或技能更新的输入。

Refactor and prune periodically. As configs grow, they can overlap or conflict with each other. As a result, if the model ignores a rule, it can be because another rule contradicts it. Fix this by refactoring periodically. Each rule or preference should live in exactly one place (though critical instructions can be repeated in the main CLAUDE.md). I also check for stray directory-level settings.json and consolidate them back into ~/.claude.定期重构和精简。随着配置的增长，它们可能会重叠或冲突。因此，如果模型忽略了一条规则，可能是因为另一条规则与之矛盾。通过定期重构来修复它。每条规则或偏好应该只存在于一个地方（尽管关键指令可以在主 CLAUDE.md 中重复）。我还检查是否有散落的目录级 settings.json，并将它们合并回 ~/.claude 中。

• • •

While the specific setup will likely change as models get better, I think the principles will remain relevant: provide good context, encode your taste, make verification cheap, delegate more, and close the loop. What we’re doing is training a collaborator, one feedback at a time. And if you think about it, these principles apply to how we work with a human team too.虽然具体的设置可能会随着模型的改进而改变，但我认为这些原则依然重要：提供良好的上下文、编码你的品味、降低验证成本、更多地委派并形成闭环。我们所做的是在训练一个合作者，一次反馈一个。如果你仔细想想，这些原则也适用于我们与人类团队的协作方式。

To get started, have your model read this SETUP.txt and help you apply it. Also, I’d love to learn what practices or principles you’ve found valuable—please comment below or reach out!要开始使用，请让你的模型阅读此 SETUP.txt 并帮助你应用它。此外，我很想了解你发现哪些实践或原则是有价值的——请在下面评论或联系我！

p.s. This isn’t just about personal tooling. It’s also how you’d design agent harnesses, set team norms, and build org infrastructure. Try reading it again with those layers in mind.附：这不仅仅关于个人工具。这也是你设计代理框架、设定团队规范和构建组织基础设施的方式。尝试带着这些层面重新阅读一遍。

If you found this useful, please cite this write-up as:如果你觉得这很有用，请引用此文为：

Yan, Ziyou. (May 2026). How to Work and Compound with AI. eugeneyan.com. https://eugeneyan.com/writing/working-with-ai/.Yan, Ziyou. (2026年5月). How to Work and Compound with AI. eugeneyan.com. https://eugeneyan.com/writing/working-with-ai/.

or

@article{yan2026default,
  title   = {How to Work and Compound with AI},
  author  = {Yan, Ziyou},
  journal = {eugeneyan.com},
  year    = {2026},
  month   = {May},
  url     = {https://eugeneyan.com/writing/working-with-ai/}
}