# How to Build an AI-Native Startup
**作者**: cyber•Fund
**日期**: 2026-05-25T16:36:16.000Z
**来源**: [https://x.com/cyberfund/status/2058950286324986294](https://x.com/cyberfund/status/2058950286324986294)
---
A practical guide for founders going from zero to AI-native: map the work, build the context, write the evals, run the loop.
By Stepan Gershuni, @cyntro_py
Read this article on the cyber.fund blog
It's 9am at two startups in the same market, founded the same month. At company one, the ops lead is still working through old support tickets, the analyst is rebuilding last week's dashboard, and the founder is on a standup about a customer call nobody's been able to resolve. Everyone is scrambling to fix yesterday’s problems and the product is stagnating.
At the second company, all of that happened overnight. Agents triaged the tickets, refreshed the dashboard, surfaced the churn risk buried in the call. The founder has already fixed the problem and is iterating on the product with his team.
Yes, founders will spend their time differently in an AI-native startup, but that’s not the fundamental change. The fundamental change is how fast the company can learn, iterate, and evolve. The second company will outlearn the first every single day. Over weeks, this will compound leverage. Over months and years, only one will succeed.
The company is AI-native when its operating model changes: fewer people coordinate less, agents execute more of the repeat work, and humans focus on direction, taste, relationships, validation, and accountability.
For founders looking to build or rebuild their companies into this new reality, it can seem like a daunting task. But it doesn’t have to be. Building AI-native starts with a few steps that when iterated upon recursively will completely reorganize the way your company operates.
It goes a little something like this:
- Map the work
- Build the context system
- Choose the simplest automation that works for each piece
- Turn repeated work into skills
- Write evals that decide whether the work is good
- Run the company loop on a weekly improvement rhythm.
## Map The Work
Step one. Start with the work graph.
List the recurring work the startup ran in the last two weeks: customer-call notes, lead research, outbound drafts, support triage, product QA, onboarding, release notes, investor updates, weekly metrics, bug reproduction, recruiting screens, invoice review, competitor monitoring, all of it. If the work repeats, it is a candidate for encoding. Most founder calendars contain 20 to 40 such items; an early-stage team that lists them honestly will find ten to fifteen they did not realize were already routine.
Classify every work unit by autonomy level:
L1 is human only: a strategic call, a final hire, a major refund, a legal signature, a board communication.
L2 is AI prepared, human approved: an investor update draft, a contract redline, a pricing-page rewrite, a support macro.
L3 is AI executes, human supervises: inbound triage, meeting-note routing, lead enrichment, test generation.
L4 is autonomous inside clear limits: competitor monitoring, nightly report generation, invoice extraction from known vendors, simple anomaly detection.
The boring workflow usually wins. A weekly strategy memo feels like the prestigious thing to automate. Daily support-tagging — which is unglamorous and repetitive — recovers more hours and gives you cleaner ground truth, because it runs ten times as often. Frequency beats prestige. The first workflow to attack is frequent, measurable, reversible, and tied to a real bottleneck.
Do not automate work that is rare, unclear, high-trust, or unstable. A C.H. Robinson team tried to push email triage at 10,000 messages per day to L4 and reverted to L2 once supervision proved infeasible; the volume hid the cost of every misroute. If the team cannot explain what good output looks like, the workflow is not ready for encoding. If one wrong output can damage a customer relationship, move slowly. If the process changes every week, wait for it to stabilize or keep it as AI-assisted human work.
When you're done with this primary step, you have one page and three workflows to start: one personal (inbox triage, daily brief, investor-update draft), one customer-facing (call synthesis, ticket classification, lead enrichment), one internal (test generation, invoice extraction, the weekly metric narrative). Having too many experiments at the same time dilutes attention and produces twenty half-finished pilots, which is the most common failure mode at this stage.
## Build The Context System
Context is the AI native startup's operating memory. It's everything the company knows about itself, held where agents can read it. While models are interchangeable and improving every month, context is the part that's actually yours. It’s what separates an agent that works like a cofounder from one that works like a confused temp.
If the team spends more time rewriting agent output than reviewing it, the problem is rarely the prompt or the model. The agent just doesn’t know enough about the company — your customers, your product, your priorities, the decisions you already made and why.
There’s an easy diagnostic you can run weekly to ascertain the state of play: pick one representative task, hand it to a fresh agent with only the workspace context, and ask for three next actions. Two or more strong suggestions means the context layer is carrying weight. Three generic answers means the context is thin and the prompt cannot rescue it.
Start with one shared Git repository every team member and agent can read. Git wins for a simple reason: it's versioned, diffable, readable by humans and agents alike, and tied to no vendor's runtime. It will outlive every model and harness you run through it. The whole workspace at day seven can be one root with CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md, and GTD.md for active work.
A general rule of thumb is to keep it to 40–60 hand-written lines; a tight list of what to avoid beats 400 generated lines of slop. It won't solve every context problem, but it solves enough that agents stop hallucinating basic facts about your own company.
As the startup grows, split the context system by permission boundaries. There are a couple of ways to do this. For example: a shared company repo plus private repos per function (sales, product, engineering, finance, support). Another: private repos per project or customer with a shared root for company-wide context.
At enterprise scale, a private Git server (self-hosted Gitea, GitHub Enterprise, GitLab) gives directory-level or repo-level permissions so agents and humans see only the context they are allowed to see. Block's internal harness Goose reads the same artifact stream the rest of the company sees, scoped by role; the moment scoping drifts, agents start mixing public-conviction language with private-deal context. That’s why boundaries are incredibly important.
Three kinds of data feed the system.
Connectors pull from outside — SaaS tools, APIs, MCP servers, email, calendar, CRM, support, analytics, GitHub, Linear, Stripe, the warehouse, the docs. Every connector needs an identity, scoped permissions, audit logs, and managed credentials, or the sprawl quietly becomes your biggest security hole. An IAM layer like Zitadel carries that identity discipline. How you load the tools matters too: Anthropic's MCP code-execution work shows a filesystem-of-server-folders pattern dropping context use from ~150,000 tokens to ~2,000 versus loading every tool definition upfront — a 98.7% cut in token spend (your accounting team will thank you).
Data the company generates — specs, customer summaries, decisions, lessons, project notes, operating rules. Markdown by default, and one rule that matters more than the rest: keep raw separate from distilled. A call transcript is raw. The decision made on that call, the objection the customer raised, the follow-up owner, the renewal risk — that's distilled, and that's what agents actually query. Keep the decision log append-only, one decision per line, so the reasoning travels with the conclusion. If you conflate raw and distilled, you’ll drown in transcripts while never building the layer that's useful.
Databases and streams, where the source of truth already lives — product data in Postgres, marketing in the warehouse, events in analytics. Don't copy it blindly into markdown. Leave the database as the source of truth, give agents a limited-read user, document the schema in an agent-facing file (data-models/postgres.md), and spell out exactly which queries and writes are allowed. Agents should not be able to delete production data by default. The Replit incident from mid-2025 — a coding agent wiped a production database mid-session — is the standing reminder that a prompt instruction is not a security boundary.
The advanced version is a structured context graph. Before agents query anything, raw artifacts get processed into entities and relationships: people, companies, objections, commitments, feature requests, renewal risks, follow-ups, dates, decisions, source links. Instead of storing transcripts, you extract what's in them and link every call with the same people or project into a chain. Now an agent can answer "what's the renewal risk on Vandelay Industries?" and cite the exact line where the customer said it.
Provenance holds the whole thing together. Every agent summary has to trace back to its source — the transcript, the ticket, the commit, the invoice, the database row. Without it, the company fills with plausible summaries nobody can verify, and the first time a confident answer turns out wrong, trust in the entire agent layer collapses. With it, agents become auditable: a teammate clicks through to the source and settles the disagreement in seconds.
## Choose The Simplest Automation That Works
Now that you’ve built the context, it may be tempting to let the machine run wild through every task in the org. Do not do this. Say it with me: Do not turn every workflow into an agent.
The best AI-native systems are a blend of scripts, AI-assisted humans, deterministic workflows, and agents, each doing the work it's actually suited for. Your job as a founder is to reach for the lightest tool that can run the work safely: the fewest moving parts that still clear the quality bar.
Use a script when the step is deterministic — exporting a report, transforming a CSV, running tests, checking links, validating JSON, formatting the weekly metric pack.
Use AI-assisted human work when the output needs judgment before it leaves the company — investor updates, founder emails, pricing copy, contract notes.
Use a workflow when the steps are known in advance — ingest the call, summarize, extract objections, write the CRM note, create the follow-up. Workflow engines (LangGraph, Temporal, Inngest, Prefect) handle the ordering, retries, and observability.
Use an agent when the path can't be pre-specified — investigate a production bug, research a market, work an unusual support case, untangle a messy customer account. Browserbase's bb agent is one Slack-facing generalist that loads a different skill file and scoped permissions for each task; that beats building a separate bot per task, because the bots all drift apart over a long enough timeline.
A harness is the essential, non-negotiable safety layer around the model. A workable first version is six stages:
1. Preflight — check context and permissions before the agent burns a token.
2. Plan — decompose the task and expose the proposed steps.
3. Approve — a human or judge-model gate that catches a bad plan before execution.
4. Execute — run the work.
5. Verify — check the output against tests, schema, rubric, or examples.
6. Log — write what happened to a run file so the next iteration has ground truth.
Guardrails belong in code and config, not in prompts. A prompt that says "do not delete production data" is not a security boundary. The non-negotiables are explicit: cost caps per run and per day, retry caps, a maximum tool-call depth, scoped credentials per agent identity, no production writes without an approval step, no auto-merge on code, and a fleet-wide kill switch. The recursive-spawning incidents through 2025 — agents calling child agents calling child agents — cost teams real money before the harness layer caught up. Caps belong at the runtime, before the model gets a chance to ignore the instruction.
## Encode Skills And Evals
Everything up to this point has been setup. Encoding recurring work as skills and grading them with evals is the engine. It’s what turns a company that does the work into one that compounds it a little better every week.
A skill is reusable instructions plus examples for a recurring task. Run it by hand twice, then encode the parts that repeat. Every skill needs a clear shape: scope, inputs, context to load, procedure, output format, examples, escalation rule, owner, and run log.
If the file doesn't say what it accepts, what it returns, when it asks for help, and who maintains it, it's a long prompt, not a skill.
Here’s a skill template founders can adapt:
> Skill: customer-call-synthesis
> Scope: sales calls after transcript is available
> Inputs: transcript, account record, product context, open opportunities
> Load: ICP, pricing, product roadmap, objection taxonomy
> Steps: extract facts → cluster objections → identify risks → write follow-ups
> Output: CRM note · customer brief · feature requests · next actions
> Examples: 3 prior calls with expected notes
> Escalate: legal or security issue, churn risk, enterprise pricing
> Owner: revenue lead
> Logs: runs/<date>/<account>.md
> Eval: 30 historical calls with expected extraction fields
Start with founder-native skills:
- Customer-call synthesis — extracts objections, feature requests, risks, commitments, and next actions from raw transcripts.
- Inbox triage — sorts investor, customer, hiring, and operational messages, and drafts replies for the first three.
- Investor update — drafts the narrative from metrics and decisions, then cites both.
- Pricing-page teardown — compares the live page against the latest customer-objection log.
- Weekly metrics narrative — explains what changed, what broke, and what to inspect.
- Test generation — turns a spec into tests and a draft PR.
The eval is what makes a skill compound. Once a skill has a usable eval, prompt-tuning becomes optional: a small reflection model proposes changes, the eval ranks them, the best one ships automatically. Without an eval, every iteration is a taste argument between the founder and whoever wrote the last version.
An eval has three layers, and they stack in order.
First, hand-labeled ground truth — a human marks what good output looks like on real examples.
Second, deterministic checks, which cost nothing and return an unambiguous verdict: schema validity, numbers matching the source, links resolving, citations existing, tests passing.
Third, an LLM judge, but only for what the deterministic checks can't reach — writing quality, sentiment, whether the output matches the brief. A small fast model is enough, and it has to be calibrated against the human-marked examples before you trust it on the rest.
Let’s take customer-call synthesis as a case study on how to achieve this. Take thirty past calls and have the revenue lead mark up each — the facts that matter, the objections, the risks, the follow-ups. Some of the checking is deterministic: did it get the names right? Do the dollar figures match the contract? Are the follow-up dates in the right week? What a machine can't check is whether the brief actually sounds like the call, so an LLM judge does that part.
About fifty runs in, you see where it breaks, and it's usually the same two things: it loses track of who's talking when three or more people are on the call, or it merges two different objections into one. Those are what you fix. The problems you imagined before running it usually aren't the ones that show up, and you rewrite the skill against these clusters until it works consistently.
While outbound lead classification works differently, the eval structure is similar. Three hundred old leads, the founder marks each a plain yes or no — fits the ICP or doesn't. The mechanical checks are basic: the company's real, the website loads, the headcount's filled in. An LLM judge against the ICP description handles the rest. With the eval in place, an open-source prompt-evolution loop (GEPA, DSPy) rewrites the classifier prompt against the labels overnight. The founder never reads the final prompt. The eval verdict is the only thing that matters.
Both cases follow the same shape: hand-labeled ground truth first, deterministic checks next, an LLM judge for what remains, and the loop runs against the eval until acceptance crosses the threshold.
Evals mature in five escalating stages:
1. Spot check one example by hand
2. Score a handful of cases against a written rubric.
3. Run that rubric against 20–300 historical cases.
4. Test on a held-out set the agent never saw
5. Track the business metric the skill was built to move.
Evals get a skill ready to ship. Staying good is a different question, and you answer it with six numbers tracked every week: acceptance rate, override rate, cost per run, cycle time, review time, and incident count.
Acceptance rate is the one to watch. Below roughly 70% — minor edits still count as accepted — the skill isn't ready to move up an autonomy level to run with less oversight than it has now. When acceptance is low, the instinct is to rewrite the prompt. That's almost never the fix. It's usually one of four moves: load more context at runtime, tighten the skill's scope, add more worked examples to the file, or write a clearer escalation rule for the cases the agent shouldn't have taken on.
## Make The Team AI-Native
The founder goes first.
The fastest way to move a team onto a new way of operating is to show them live, within the context of your company. Show the morning brief that pulled from calendar, inbox, and Slack overnight; the customer synthesis from yesterday's calls; the test PR an agent opened against the spec; the investor-update draft built from the last metric pack.
The goal is calibration: seeing firsthand what the agent layer can and can't do. Jack Dorsey reportedly spent hours every morning through 2025 working directly with these tools before Block reorganized around them. It led to huge efficiency restructuring, and the decisions behind it came from leadership that had used the agents themselves.
Installation begins on day one. Onboarding should end with a useful AI artefact. Every teammate walks out of their first session with output they can ship that day — a cleaned customer brief, a support macro, a test PR, a pricing-page critique. Training that doesn't produce real work gets forgotten by the next week. Ramp's Glass tool went from 20 daily users to around 700 in three months on exactly this rule: every onboarding session ended with the new person adding one skill or one artifact to the shared library.
This means the human role gets bigger, not smaller. People design the system, own the relationships, judge the output, and carry the accountability. The agents handle execution. The teammate who only runs narrow tasks is exposed under this model. The one who can turn judgment into instructions, examples, and evals is worth more than they were before.
Hiring changes too. The bar for opening a role is higher now. Some of what used to need a hire is now a skill, so save new roles for the work that genuinely needs a person. When you do hire, test for the new shape of the job: skip the trivia, hand candidates a project too big to finish by hand in the time given, and watch how they direct agents through it. You're hiring for judgment, taste, and the ability to recover when an agent goes sideways. These are the parts of the work that just got more valuable.
What that looks like in practice: an analyst gets a real report to produce in three hours, sources collected and evidence pulled and a polished brief at the end. An engineer gets a day to clone a real product surface or build an internal tool from a spec, tests included. A growth hire gets a market map and campaign plan across 50 to 100 companies — scraping, clustering, writing, prioritizing. None of it is finishable by hand in the time given. That's the point: you're watching how they work with agents under pressure.
## Run The Startup As A Feedback Loop
By this point, you’ve pressure tested your automation and your team. Now you go back to the beginning and start again. An AI-native startup improves its operating system every week.
The review should address:
- what agents did
- where humans overrode them
- which evals failed
- which context was missing
- which skills need narrowing
- which workflows to kill
- which to move up an autonomy level.
Run two loops at once. The inner loop makes existing work better — lower cost per run, shorter cycle time, fewer incidents, less review time per artifact. The outer loop hunts for what's next: new customer segments, product ideas, pricing changes, partnerships, competitor moves, regulatory shifts, churn risk. Background agents feed the outer loop with candidates around the clock; humans decide which ones to chase.
The software factory is the biggest piece of the inner loop. Humans write the specs and tests, agents implement against them. Deterministic checks run on their own, humans review before anything merges. Start where the acceptance criteria are clear and the blast radius is small: test generation, dependency upgrades, migrations, internal tools, integration scaffolds, QA scripts, security autofixes.
There are two hard rules: nothing auto-merges, and no agent writes to production. Even Cursor, running autonomous cloud agents at scale, kept a human review gate on merges through early 2026. The gate is what let them scale the rest safely.
The market-learning system is the outer loop. Record the calls, extract objections, cluster feature requests, track competitors, watch usage shift, read the support patterns, study the deals you lost. Turn what you find into hypotheses, then test the strongest ones — customer conversations, landing-page tests, product experiments, fresh queries against the data. The agents propose. You choose. Hand an agent both the proposing and the deciding on strategy and it either settles into bland consensus or hill-climbs whatever metric is easiest to move.
Company-level self-improvement comes down to one skill: whether the team can write evals. Hand-label a few hundred examples good or bad, build the eval, wire it to a prompt-evolution loop. GEPA, DSPy, and frameworks like them do this directly — a small reflection model proposes prompt mutations, the eval ranks them on the labeled set, the winner ships, and it repeats. The founder writes the eval and reads the failure clusters. The founder never writes or reads the evolved prompt.
Agent capability is rarely the thing holding you back. If you can encode what good looks like — binary labels, a scoring rubric, a few business metrics — the loop runs at the scale of the whole company. If you can't, no amount of model capability closes the gap. Coding helps, but it isn't the bottleneck; a subject-matter expert who can reliably mark output good or bad can run the entire loop. The eval is the load-bearing artifact. The company stops compounding the moment the eval stops being written.
None of this needs a genius or a big team. It needs the discipline to map the work, build the context, write the evals, and run the loop every week. Discipline is the moat now. Everyone has the same models; the operating system is the secret sauce.
The Monastery exists to build that operating system with you: twelve weeks of pure focus, $2M, and operators already running the loop working alongside you to embed it into your company from day one.
Enter the Monastery, do the impossible with us.
## 相关链接
- [cyber•Fund](https://x.com/cyberfund)
- [@cyberfund](https://x.com/cyberfund)
- [25K](https://x.com/cyberfund/status/2058950286324986294/analytics)
- [@cyntro_py](https://x.com/@cyntro_py)
- [cyber.fund](https://cyber.fund/content/how-to-build-an-ai-native-startup)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:36 AM · May 26, 2026](https://x.com/cyberfund/status/2058950286324986294)
- [25.4K Views](https://x.com/cyberfund/status/2058950286324986294/analytics)
- [View quotes](https://x.com/cyberfund/status/2058950286324986294/quotes)
---
*导出时间: 2026/5/26 09:11:51*
---
## 中文翻译
# 如何打造 AI 原生创业公司
**作者**： cyber•Fund
**日期**： 2026-05-25T16:36:16.000Z
**来源**： [https://x.com/cyberfund/status/2058950286324986294](https://x.com/cyberfund/status/2058950286324986294)
---
一份面向创始人的实用指南，助你从零迈向 AI 原生：梳理工作、构建上下文、编写评估、运行循环。
作者：Stepan Gershuni，@cyntro_py
在 cyber.fund 博客上阅读本文
早上九点，同一个月创立、处于同一市场的两家创业公司。在第一家公司，运营负责人还在处理积压的客服工单，分析师在重建上周的仪表板，创始人正在开站会讨论一通始终没人能解决的客户来电。所有人都在手忙脚乱地修补昨天的问题，产品停滞不前。
在第二家公司，这一切都在一夜之间完成了。智能体已经对工单进行了分类，刷新了仪表板，并挖掘出了藏在通话中的流失风险。创始人已经解决了问题，正在与团队一起迭代产品。
是的，在 AI 原生创业公司里，创始人的时间分配会有所不同，但这并不是根本性的变化。根本性的变化在于公司学习、迭代和演进的速度。第二家公司每一天都会比第一家学得更快。几周之后，这将形成复利式的杠杆。几个月乃至几年之后，只有一家能够成功。
当公司的运营模式发生改变时，它就是 AI 原生的：更少的人进行更少的协调，智能体执行更多的重复性工作，而人类则专注于方向、品味、关系、验证和问责。
对于希望按照这一新现实来打造或重塑公司的创始人来说，这似乎是一项艰巨的任务。但其实不必如此。打造 AI 原生公司从几个步骤开始，只要递归地迭代这些步骤，就会彻底重组公司的运作方式。
大致流程如下：
- 梳理工作
- 构建上下文系统
- 为每一项工作选择最简单可行的自动化方式
- 把重复性工作转化为技能
- 编写判断工作质量的评估
- 以每周改进的节奏运行公司循环
## 梳理工作
第一步。从工作图谱开始。
列出创业公司过去两周内运行的重复性工作：客户通话记录、线索调研、外联草稿、支持工单分类、产品 QA、新用户引导、发布说明、投资人更新、每周指标、Bug 复现、招聘初筛、发票审核、竞争对手监控——所有这些。只要工作会重复出现，它就是编码的候选对象。大多数创始人的日程中包含 20 到 40 项此类工作；一个早期团队只要诚实地列出，就会发现其中十到十五项其实早已成为例行事务，只是自己没有意识到。
按自主程度对每个工作单元进行分类：
L1 仅由人类完成：战略决策、最终录用、重大退款、法律签署、董事会沟通。
L2 由 AI 准备、人类批准：投资人更新草稿、合同修订、定价页改写、客服模板。
L3 由 AI 执行、人类监督：入站工单分类、会议记录分发、线索信息补全、测试生成。
L4 在明确界限内自主运行：竞争对手监控、夜间报告生成、从已知供应商的发票中提取信息、简单的异常检测。
枯燥的工作流程通常胜出。每周战略备忘录听起来像是最值得自动化的东西。而每日客服标签工作——虽然不起眼且重复——却能挽回更多时间，并给你更干净的基准数据，因为它的运行频率是十倍。频率胜过光鲜度。首个要攻下的工作流程应该具备高频、可衡量、可逆，且与真实瓶颈相关这几个特点。
不要自动化那些罕见、不清晰、高信任度或流程不稳定的的工作。C.H. Robinson 的一个团队曾试图把每天 1 万封邮件的分类推向 L4，但发现监督不可行后又退回了 L2；庞大的业务量掩盖了每次误分类的成本。如果团队无法解释什么样的输出才算好，这个工作流程就还没准备好被编码。如果一个错误输出就可能损害客户关系，那就放缓脚步。如果流程每周都在变化，就等它稳定下来，或者把它保持为 AI 辅助的人类工作。
完成这个基础步骤后，你手上会有一页纸和三个起步的工作流程：一个面向个人（收件箱分类、每日简报、投资人更新草稿），一个面向客户（通话综合、工单分类、线索补全），一个面向内部（测试生成、发票提取、每周指标叙述）。同时进行太多实验会稀释注意力，产生二十个半途而废的试点项目——这是这个阶段最常见的失败模式。
## 构建上下文系统
上下文是 AI 原生创业公司的运营记忆。它是公司对自身所知的一切，存放在智能体可以读取的地方。模型可以互相替换且每个月都在进步，但上下文才是真正属于你的部分。它决定了一个智能体是像联合创始人那样工作，还是像一个晕头转向的临时工。
如果团队花在重写智能体输出上的时间比审查它们的时间还多，问题很少出在提示词或模型上。只是智能体对公司的了解不够——你的客户、你的产品、你的优先事项、你已经做过的决策及其原因。
有一个简单的诊断方法可以每周运行一次，以了解当前状况：选一个有代表性的任务，交给一个全新的智能体，只提供工作区上下文，让它提出三个下一步行动。两个或以上高质量的建议，说明上下文层发挥了作用。三个泛泛的回答，则说明上下文太薄弱，提示词也无法挽救。
从一个人人和智能体都能读取的共享 Git 仓库开始。Git 胜出的原因很简单：它有版本控制、可对比差异、人类和智能体都可读，并且不依赖任何厂商的运行时。它的寿命将超过你使用的每一个模型和框架。到第七天，整个工作区可以只是一个根目录，包含 CLAUDE.md、context/company.md、context/product.md、context/customers.md、context/lessons.md，以及用于活跃工作的 GTD.md。
一条通用的经验法则是把它控制在 40–60 行手写内容；一份精炼的“该避免什么”清单，胜过 400 行生成的灌水内容。它不能解决所有上下文问题，但足以让智能体不再对你自己公司的基本事实产生幻觉。
随着初创公司成长，可以按权限边界拆分上下文系统。有几种做法。例如：一个共享的公司仓库，加上每个职能部门（销售、产品、工程、财务、支持）各自的私有仓库。另一种：每个项目或客户各一个私有仓库，另设一个共享根目录存放全公司范围的上下文。
在企业规模下，私有 Git 服务器（自托管的 Gitea、GitHub Enterprise、GitLab）可以提供目录级或仓库级权限，让智能体和人类只能看到他们被允许看到的上下文。Block 的内部框架 Goose 读取的工件流与公司其他人看到的相同，但按角色划分范围；一旦范围划分出现偏差，智能体就会开始把公开表态的语言与私下交易的上下文混在一起。这就是为什么边界至关重要。
三类数据为这个系统提供输入。
连接器从外部拉取数据——SaaS 工具、API、MCP 服务器、邮件、日历、CRM、支持系统、分析工具、GitHub、Linear、Stripe、数据仓库、文档。每个连接器都需要身份、范围受限的权限、审计日志和托管的凭证，否则这种无序扩张会悄悄变成你最大的安全漏洞。像 Zitadel 这样的 IAM 层承担了这种身份管理纪律。工具的加载方式也很重要：Anthropic 的 MCP 代码执行工作展示了一种“服务器文件夹文件系统”模式，与一开始就加载所有工具定义相比，把上下文使用量从约 150,000 token 降至约 2,000 token——节省了 98.7% 的 token 开支（你的财务团队会感谢你的）。
公司自己生成的数据——规格说明、客户摘要、决策、经验教训、项目笔记、运营规则。默认使用 Markdown，并且有一条规则比其他所有规则都重要：把原始数据和提炼后的内容分开。通话记录是原始数据。在那次通话中做出的决定、客户提出的异议、跟进的负责人、续约风险——这些是提炼后的内容，也是智能体真正会查询的东西。让决策日志只允许追加，一行一条决策，这样推理过程就随结论一起留存。如果你把原始数据和提炼内容混在一起，你会淹没在通话记录里，却永远建不起那一层真正有用的东西。
数据库和流，即事实源头已经存在的地方——产品数据在 Postgres 里，营销数据在数据仓库里，事件在分析工具里。不要盲目地把它们复制成 Markdown。让数据库继续作为事实源头，给智能体一个只读受限的用户，把数据模式记录在一个面向智能体的文件里（data-models/postgres.md），并明确写出允许哪些查询和写入操作。默认情况下，智能体不应能删除生产数据。2025 年年中的 Replit 事件——一个编程智能体在会话中途清空了生产数据库——就是常设的提醒：提示词指令不是安全边界。
进阶版本是结构化的上下文图谱。在智能体查询任何内容之前，原始工件会被处理成实体和关系：人员、公司、异议、承诺、功能请求、续约风险、跟进事项、日期、决策、来源链接。不用存储通话记录，而是提取其中的内容，并把涉及相同人员或项目的每次通话链接成一条链。这样智能体就能回答“Vandelay Industries 的续约风险是什么？”，并引用客户说这句话的确切原话。
溯源把整个体系维系在一起。每个智能体摘要都必须能追溯到其来源——通话记录、工单、提交、发票、数据库行。没有溯源，公司里会充斥着没人能验证的、貌似合理的摘要，一旦某个自信满满的答案被证明是错的，对整个智能体层的信任就会崩塌。有了溯源，智能体就变得可审计：同事点开源头，几秒钟内就能化解分歧。
## 选择能用的最简单自动化方式
既然你已经建好了上下文，可能会忍不住让机器在组织的每项任务中肆意运行。不要这样做。跟我念：不要把每个工作流都变成智能体。
最好的 AI 原生系统是脚本、AI 辅助的人类、确定性工作流和智能体的混合体，各自做真正适合它的工作。作为创始人的你的任务是，选择能够安全运行这项工作的最轻量工具：在仍能达到质量标准的前提下，用最少的活动部件。
当步骤是确定性的时候，用脚本——导出报告、转换 CSV、运行测试、检查链接、验证 JSON、格式化每周指标包。
当产出在离开公司之前需要人类判断时，用 AI 辅助的人工工作——投资人更新、创始人邮件、定价文案、合同备注。
当步骤事先已知时，用工作流——摄取通话、总结、提取异议、写 CRM 备注、创建跟进事项。工作流引擎（LangGraph、Temporal、Inngest、Prefect）负责处理排序、重试和可观测性。
当路径无法预先指定时，用智能体——排查生产环境的 bug、研究一个市场、处理一个不寻常的支持案例、理清一个混乱的客户账户。Browserbase 的 bb 智能体就是一个面向 Slack 的通用型智能体，它为每个任务加载不同的技能文件和范围受限的权限；这比为每个任务单独构建一个机器人更好，因为时间一长，这些机器人都会各自漂移。
框架（harness）是围绕模型不可或缺、不容妥协的安全层。一个可行的第一版包含六个阶段：
1. 预检——在智能体消耗任何 token 之前，先检查上下文和权限。
2. 规划——分解任务，并展示拟定的步骤。
3. 批准——由人工或评审模型把关，在执行前拦截糟糕的计划。
4. 执行——运行工作。
5. 验证——根据测试、schema、评分标准或示例检查输出。
6. 记录——把发生的事情写入运行日志文件，让下一次迭代有真实依据可循。
护栏应该写在代码和配置里，而不是提示词里。一句“不要删除生产数据”的提示词并不是安全边界。不可妥协的事项必须明确：每次运行和每日的成本上限、重试上限、最大工具调用深度、按智能体身份划分的受限凭证、未经审批环节不得写入生产环境、代码不得自动合并，以及全局一键终止开关。2025 年发生的那些递归生成事件——智能体调用子智能体，子智能体又调用子智能体——在护栏层跟上之前，让团队付出了真金白银的代价。上限应该设置在运行时层，在模型有机会无视指令之前。
## 将技能与评测编码化
前面讲的一切都只是准备工作。把重复性工作编码为技能并用评测来打分，才是真正的引擎。正是这一点，把一家“自己干活”的公司，变成一家每周都能把工作做得更好一点、不断复利的公司。
技能就是针对重复性任务的可复用指令加示例。先手动跑两遍，再把重复的部分编码下来。每项技能都需要清晰的结构：范围、输入、需加载的上下文、流程步骤、输出格式、示例、升级规则、负责人和运行日志。
如果一个文件没有说明它接受什么、返回什么、什么时候请求帮助、由谁维护，那它就只是一个长提示词，而不是技能。
以下是一个创始人可以直接套用的技能模板：
> 技能：customer-call-synthesis（客户通话综合分析）
> 范围：销售通话，转录稿可用后
> 输入：转录稿、客户账户记录、产品上下文、进行中的商机
> 加载：ICP（理想客户画像）、定价、产品路线图、异议分类体系
> 步骤：提取事实 → 聚类异议 → 识别风险 → 撰写跟进事项
> 输出：CRM 备注 · 客户简报 · 功能需求 · 下一步行动
> 示例：3 个历史通话及其预期备注
> 升级：法律或安全问题、流失风险、企业级定价
> 负责人：收入负责人
> 日志：runs/<日期>/<账户>.md
> 评测：30 个历史通话及预期的提取字段
从创始人自己最熟悉的技能入手：
- 客户通话综合分析——从原始转录稿中提取异议、功能需求、风险、承诺和下一步行动。
- 收件箱分诊——对投资人、客户、招聘和运营类消息分类，并为前三类起草回复。
- 投资人更新——根据指标和决策起草叙述内容，并引用两者作为依据。
- 定价页拆解——将线上定价页与最新的客户异议记录进行对比。
- 每周指标叙述——解释发生了什么变化、哪里出了问题、需要检查什么。
- 测试生成——把规格说明转化为测试和一个 PR 草稿。
评测才是让技能产生复利的关键。一旦一项技能有了可用的评测，提示词调优就变成了可选项：一个小型反思模型提出修改建议，评测对它们排序，最优版本自动上线。没有评测，每一次迭代都只是创始人跟上一个版本作者之间的品味之争。
评测有三个层次，按顺序叠加。
第一，人工标注的真实标准——由人标记出真实示例中好的输出是什么样子。
第二，确定性检查，零成本且结论明确：schema 是否有效、数字是否与来源一致、链接是否可解析、引用是否存在、测试是否通过。
第三，LLM 评审模型，但仅用于确定性检查覆盖不到的部分——写作质量、情感倾向、输出是否符合要求。一个小型快速模型就足够了，但在信任它处理其余内容之前，必须先对照人工标注的示例进行校准。
我们以客户通话综合分析为例，看看如何做到这一点。取三十个历史通话，让收入负责人逐一标注——关键事实、异议、风险、跟进事项。其中一部分检查是确定性的：人名对不对？金额是否与合同一致？跟进日期是否落在正确的周？机器无法检查的是简报读起来是否真的像那次通话，这部分就交给 LLM 评审模型。
跑到大约五十次时，你会看到它在哪里出错，而且通常是同样两个问题：当通话中有三个或更多人说话时，它分不清谁在说什么；或者它把两个不同的异议合并成一个。你要修的就是这些。你在跑之前想象出来的问题，通常并不是实际出现的问题，你要针对这些错误聚类重写技能，直到它稳定可靠为止。
外呼线索分类的运作方式不同，但评测结构类似。取三百条旧线索，创始人对每一条简单标注是或否——符合 ICP 或不符合。机械检查很基础：公司是否真实存在、网站能否打开、员工人数是否填写。剩下的交给对照 ICP 描述的 LLM 评审模型。评测就位后，一个开源的提示词进化循环（GEPA、DSPy）一夜之间就能根据标注重写分类器提示词。创始人从不需要阅读最终的提示词。评测的结论才是唯一重要的。
两种情况遵循同样的模式：先人工标注真实标准，其次确定性检查，再用 LLM 评审模型处理剩余部分，循环针对评测不断运行，直到通过率越过阈值。
评测按五个递进阶段逐步成熟：
1. 手动抽查一个示例
2. 按照成文的评分标准为少量案例打分。
3. 将该评分标准应用于 20–300 个历史案例。
4. 在智能体从未见过的留出集上测试
5. 追踪该技能旨在推动的业务指标。
评估（Evals）能让技能达到可交付的状态。而保持良好则是另一个问题，你需要用每周追踪的六个数字来回答：接受率、人工否决率、单次运行成本、周期时间、审查时间和事故数量。
接受率是最需要关注的指标。低于大约 70% 时——微小的修改仍算作被接受——该技能就还没准备好提升一个自主级别，以比现在更少的监督来运行。当接受率较低时，人们的本能是重写提示词（prompt）。这几乎从来不是正确的修复方法。通常要做的是以下四种动作之一：在运行时加载更多上下文、收紧技能的范围、向文件中添加更多实际示例，或者为 Agent 不应该承担的情况写一条更清晰的升级规则。
## 让团队 AI 原生化
创始人要率先垂范。
让团队转向新运营方式的最快方法，是在你们公司的实际场景中向他们现场展示。展示那份连夜从日历、收件箱和 Slack 中汇总的晨报；来自昨天客户通话的客户综合分析；Agent 针对规格说明开启的测试 PR；基于最近一次指标包构建的投资者更新草稿。
目标是校准：亲眼看到 Agent 层能做什么、不能做什么。据报道，Jack Dorsey 在 2025 年整个期间每天早上都花数小时直接使用这些工具，之后 Block 才围绕它们进行了重组。这带来了巨大的效率重构，而背后的决策来自于亲自使用过这些 Agent 的领导层。
安装（Installation）从第一天开始。入职培训（Onboarding）应该以一个有用的 AI 产物（artefact）结束。每位团队成员在第一次培训结束时都应该带着当天就能交付的成果离开——一份整理好的客户简报、一个客服宏、一个测试 PR、一份定价页批评分析。不能产生实际工作的培训，到下一周就会被遗忘。Ramp 的 Glass 工具在三个月内从每天 20 个用户增长到约 700 个用户，正是靠这条规则：每次入职培训都以新人向共享库中添加一个技能或一个产物而结束。
这意味着人类的角色变得更大，而不是更小。人们设计系统、掌控关系、评判产出、承担责任。Agent 负责执行。在这种模式下，只会执行狭窄任务的成员会暴露出短板。而能够将判断力转化为指令、示例和评估的人，会比以前更有价值。
招聘也随之改变。现在开设一个岗位的门槛更高了。过去需要招聘的一些工作现在是技能，所以要把新岗位留给真正需要人来完成的工作。当你确实要招聘时，要针对工作的全新形态进行测试：跳过琐碎的知识问答，给候选人一个在给定时间内无法靠手工完成的大项目，观察他们如何指挥 Agent 完成它。你招聘的是判断力、品味，以及在 Agent 跑偏时恢复局面的能力。这些正是工作中刚刚变得更值钱的部分。
实践中是什么样子：给分析师三个小时完成一份真实报告——收集资料、提取证据，最后拿出一份打磨过的简报。给工程师一天时间去克隆一个真实的产品界面，或者根据规格说明构建一个内部工具，包括测试。给增长岗位候选人一份涵盖 50 到 100 家公司的市场地图和营销活动计划——抓取、聚类、撰写、排优先级。在给定时间内没有一项能靠手工完成。这就是重点所在：你要观察的是他们在压力下如何与 Agent 协作。
## 把创业公司当作一个反馈循环来运营
到这时，你已经对你的自动化和你的团队进行了压力测试。现在你回到起点，重新开始。一家 AI 原生创业公司每周都在改进它的操作系统。
复盘应该涉及以下内容：
- Agent 做了什么
- 人类在哪里否决了它们
- 哪些评估失败了
- 缺失了哪些上下文
- 哪些技能需要收窄
- 哪些工作流应该砍掉
- 哪些应该提升一个自主级别。
同时运行两个循环。内循环让现有工作变得更好——更低的单次运行成本、更短的周期时间、更少的事故、每个产物更少的审查时间。外循环寻找下一步的机会：新的客户细分、产品创意、定价调整、合作伙伴关系、竞争对手动向、监管变化、流失风险。后台 Agent 全天候为外循环提供候选项；人类决定追逐哪些。
软件工厂是内循环中最大的一块。人类编写规格和测试，Agent 针对它们进行实现。确定性检查自动运行，人类在任何代码合并之前进行审查。从验收标准清晰且影响范围小的地方开始：测试生成、依赖升级、迁移、内部工具、集成脚手架、QA 脚本、安全自动修复。
有两条硬性规则：任何东西都不自动合并，任何 Agent 都不写入生产环境。即使是大规模运行自主云端 Agent 的 Cursor，到 2026 年初也仍在合并环节保留人工审查关卡。正是这道关卡让他们得以安全地扩展其余部分。
市场学习系统是外循环。录制通话、提取异议、聚类功能请求、追踪竞争对手、关注使用情况的变化、阅读客服模式、研究你失去的订单。把你发现的东西转化为假设，然后测试其中最强的那些——客户对话、落地页测试、产品实验、针对数据的新查询。Agent 负责提议。你来做选择。如果把战略上的提议权和决定权都交给一个 Agent，它要么陷入平庸的共识，要么就朝着最容易提升的那个指标进行爬山式优化。
公司层面的自我改进归结为一项技能：团队是否能编写评估。人工标注几百个好或坏的示例，构建评估，把它接入一个提示词进化循环。GEPA、DSPy 及类似框架可以直接做到这一点——一个小型反思模型提出提示词变异，评估在标注集上对它们进行排序，胜出者上线，然后循环往复。创始人编写评估并阅读失败聚类。创始人从不编写或阅读进化后的提示词。
Agent 能力很少是真正限制你的因素。如果你能把“什么算好”编码下来——二分类标签、评分细则、几个业务指标——这个循环就能以整个公司的规模运转。如果你不能，再多模型能力也无法填补这个缺口。编程有帮助，但它不是瓶颈；一位能够可靠地判定输出好坏的领域专家就能运转整个循环。评估才是承重件。评估停止被编写的瞬间，公司就停止复利增长。
这一切不需要天才，也不需要庞大的团队。它需要的是纪律：梳理工作、构建上下文、编写评估，并每周运转这个循环。如今，纪律才是护城河。所有人都用着同样的模型；操作系统才是秘密武器。
Monastery 的使命就是与你共建这个操作系统：十二周的纯专注、200 万美元，以及已经在运转这一循环的实战运营者，从第一天起就与你并肩，将其植入你的公司。
加入 Monastery，与我们一起做不可能的事。
## 相关链接
- [cyber•Fund](https://x.com/cyberfund)
- [@cyberfund](https://x.com/cyberfund)
- [25K](https://x.com/cyberfund/status/2058950286324986294/analytics)
- [@cyntro_py](https://x.com/@cyntro_py)
- [cyber.fund](https://cyber.fund/content/how-to-build-an-ai-native-startup)
- [升级至 Premium](https://x.com/i/premium_sign_up)
- [2026年5月26日 凌晨12:36](https://x.com/cyberfund/status/2058950286324986294)
- [25.4K 次浏览](https://x.com/cyberfund/status/2058950286324986294/analytics)
- [查看引用](https://x.com/cyberfund/status/2058950286324986294/quotes)
---
*导出时间: 2026/5/26 09:11:51*
