---
title: "技术、产品与合作模式术语表"
canonical: https://wavect.io/zh/glossary/
language: zh
description: "我们在网站上提到的每一种角色、合作模式、技术与方法的定义。由真正做这份工作的运营者撰写，用一种创始人、CFO 或董事会成员当天就能直接使用的语言。"
image: "https://wavect.io/img/general/bak/open_graph_preview.jpg"
---

// 参考资料 / 通俗用语 / 不废话

# Wavect 术语表

我们在网站上提到的每一种角色、合作模式、技术与方法的定义。由真正做这份工作的运营者撰写，用一种创始人、CFO 或董事会成员当天就能直接使用的语言。

73 条

角色 13

合作模式 15

技术 27

方法 18

讲不清这个词的人，就报不出这份合同的价。

// 01

## 我们为什么发布这个

我们行业里一半的流行词，根据谁在卖，都会代表三种不同含义。一位创始人在同一周里听到 CTPO、Fractional CTO 与 Werkvertrag，理应知道到底是哪一个词真正改变了发票上的数字。这份术语表是我们公开的参考：简短、有立场、对取舍坦诚、保持更新。

// 02

## 按分类浏览

全部 73 条 角色 13 合作模式 15 技术 27 方法 18

## 角色与运营模式

角色 · 13

谁负责什么、有什么权限、按什么时间投入。

001 / 073 roles [#](#ctpo)

亦称: Chief TPO

由一位运营者同时承担技术与产品路线图的负责人，适用于把这两个 C-level 拆成两个人雇用太慢或太贵的阶段。

CTPO 把 [CTO](/zh/glossary/cto/) 与 [CPO](/zh/glossary/cpo/) 的职责扛在一个人头上。他负责要造什么、怎么造，以及它是否真正解决客户的问题。这个角色存在的原因是：PMF 之前的初创公司既无力承担两个高级聘用，也无力承受 CTO 与 CPO 每个星期二为优先级争吵的政治成本。

早期合并这个角色为什么更胜一筹，举个实际例子：一家两位创始人的初创公司不断去做嗓门最大的投资人要的功能，因为技术联合创始人造的就是产品对话落到的那个东西，而没人负责排序。CTPO 收紧了这个循环。决定结账改版比仪表盘更重要的那个人，同时也决定它怎么架构、能不能在这个 Sprint 里发布。没有交接、没有翻译层，也没有两位 C-level 自尊心之间每周二的对峙，而这正是 PMF 之前最大的 Runway 浪费来源。

在 Wavect 的项目中，CTPO 多数是 fractional 的。对已有早期牵引的团队，我们以一份专门的 [Fractional CTPO](/zh/services/fractional-ctpo/) retainer 来承担；在 PMF 之前，同一个合并角色则通过我们的 [Fractional Co-Founder](/zh/services/fractional-cofounder/) 模式交付。一位运营者在同一周里同时跑产品发现与技术架构，等公司有了营收与组织结构能支撑两人时，再交接给永久的拆分（CTO + CPO）。在奥地利，这种合作通常是 freier Dienstvertrag，因为交付的是持续的判断，而不是一个固定的成果物。

诚实的取舍与创始人常犯的错误：一个人会变成单点故障，而创始人爱上了这份便利，把 CTPO 留得远超这个角色本应拆分的时点。缓解方法是一位知道何时该停止做 CTPO 并去招自己继任者的 CTPO；任何不愿意把自己「下岗」的人，都是错的 CTPO。这个角色应当在工程管理变成全职工作时（通常 8 人以上）、且产品已经等不及每周打包优先级时拆分。在那之前拆分只会制造协调税。相关： [Fractional CTO 奥地利](/zh/services/fractional-cto/) 。

另见 [CTO](/zh/glossary/cto/) / [CPO](/zh/glossary/cpo/) / [Fractional Co-Founder](/zh/glossary/fractional-cofounder/) / [Fractional CTO](/zh/glossary/fractional-cto/) / [Fractional CPO](/zh/glossary/fractional-cpo/) / [Product Engineer](/zh/glossary/product-engineer/)

[阅读完整定义 →](/zh/glossary/ctpo/)

002 / 073 roles [#](#cto)

对技术选型、工程交付与会出现在董事会议程上的技术风险负责的高管。

CTO 拥有三件事：你在什么之上构建、交付得有多稳定，以及你两年前选的架构今天是否还服务于业务。他不只是最资深的工程师，也不是换了个气派头衔的资深 [Tech Lead](/zh/glossary/tech-lead/) 。他是决定哪些火该灭、哪些火该明确承认并搁置的运营者，也是那个扛起会落到董事会议程上的技术风险的人。

在 Wavect 我们区分三种形态。Founding CTO 在股权表上，且扎在战壕里亲自写代码。Scale-up CTO 下面有 20+ 工程师，主要通过一层 [Engineering Manager](/zh/glossary/engineering-manager/) 来管工程。 [Fractional CTO](/zh/glossary/fractional-cto/) 被请来填补：营收还不足以支撑前两种全职角色时的那段空缺。

最常见也最昂贵的错误，举个实际例子：一家种子轮初创公司融了一轮钱，被建议「招一个真正的 CTO」，于是从一家有 200 名工程师的公司挖来一个响亮的名字。那个人花了五年管组织架构图和预算，不写代码，如今落到一支四人团队里，而这支团队需要的是有人亲自架构系统并自己把它发布出来。半年加四分之一 Runway 之后，团队有了流程和幻灯片，产品却几乎没动。简历是真的，只是对这个阶段而言是错的形态。让人选匹配阶段，而不是匹配 logo。

创始人回避的诚实取舍：一个能造东西的 Founding 形态 CTO 终究会在管理那一侧撞到天花板，而一个会管理的 Scale-up CTO 在只有四名工程师时既被浪费也很无聊。这个角色确实会随公司成长而改变，所以问题很少是「我们需不需要 CTO」，而是「这个阶段需要哪一种 CTO」。当答案是「要决策权但还不要全职成本」时，fractional 版本就能覆盖。Wavect 的支柱型合作参见 [Fractional CTO 奥地利](/zh/services/fractional-cto/) 。

另见 [CTPO](/zh/glossary/ctpo/) / [CPO](/zh/glossary/cpo/) / [Fractional CTO](/zh/glossary/fractional-cto/) / [Tech Lead](/zh/glossary/tech-lead/) / [Engineering Manager](/zh/glossary/engineering-manager/)

[阅读完整定义 →](/zh/glossary/cto/)

003 / 073 roles [#](#cpo)

对要做什么、不做什么以及产品最终是否能推动业务关键指标负责的高管。

CPO 负责产品本身。不是设计、不是工程、不是营销，而是「要把什么、按什么顺序送到客户面前」这个问题。这个角色存在的原因是：每一次发布决定，同时也是一次不发布别的东西的决定，规模一大，这个选择就需要有人负责。把它和 [CTO](/zh/glossary/cto/) 的职责合在一个人身上，你得到的是 [CTPO](/zh/glossary/ctpo/) ；让它保持兼职，你得到的是 [Fractional CPO](/zh/glossary/fractional-cpo/) 。

一名好的 CPO 流利地讲三种语言：客户（哪里痛）、工程师（什么可行）、高管层（什么能撬动 P&L）。当这三种里缺了一种，就会出现产品债：做出来没人买的功能，或卖得出去却没人造的功能。

缺少一门语言的失败，举个实际例子：一位从销售主导型组织直接招来的 CPO，流利于 P&L 与客户，却读不懂工程关于成本告诉他的东西。他把路线图押在一个季度的「快赢」上，而那其实是悄悄藏着六个月的平台工程，日期开始滑坡，双方的信任都被侵蚀。镜像式的失败是工程师转岗的 CPO，能给任何东西定范围，却说不清哪个功能真正撬动营收。这份工作就是这三者之间的翻译，任何一门弱了，都会表现为自信地造错了东西。

诚实的取舍与常见错误：创始人太早伸手去要一位专职 CPO。在 [PMF](/zh/glossary/pmf/) 之前这个角色是过度配置，因为创始人自己对客户的直觉是公司里最有价值的产品资产，无法被委派出去。这份工作会被创始人或一位 CTPO 吸收，直到工程团队规模大到「决定下一个造什么」本身就是全职工作。在那个时点之前，招一位 CPO 多半只是在创始人和客户之间加了一层，而这恰恰与早期产品所需的相反。相关： [Fractional CTO 奥地利](/zh/services/fractional-cto/) 。

另见 [CTPO](/zh/glossary/ctpo/) / [CTO](/zh/glossary/cto/) / [Fractional CPO](/zh/glossary/fractional-cpo/) / [MVP](/zh/glossary/mvp/) / [PMF](/zh/glossary/pmf/)

[阅读完整定义 →](/zh/glossary/cpo/)

004 / 073 roles [#](#fractional-cofounder)

亦称: Fractional Cofounder / 兼职联合创始人

以联合创始人式合同兼职加入你公司、扎在前线的产品型技术运营者，直到你能负担或吸引到全职接替者。

Fractional Co-Founder 是 Wavect 的旗舰服务，名副其实。我们以联合创始人会嵌入的层级嵌入：产品策略、技术架构、Sprint 计划、客户对话、董事会准备。用角色来说，它通常是一位 fractional [CTPO](/zh/glossary/ctpo/) ，产品与技术在一个人头上。我们不带记录工时的工时表登场，我们带结果登场。

定价：每周 400 欧元，每周可终止，无须提前通知，无退出费。如果没有把你惊艳到，最后一周费用退还。我们这么做是因为不合适对双方都太贵。一段干净结束的两周试合作，胜过一份拖着腿走了六个月的合同。

什么时候这是正确的形态，举个实际例子：一位非技术创始人有营收，却不断地雇外包，造出来的总是错的东西，因为内部没人能挑战 brief。一位 Fractional Co-Founder 坐在他和建造者之间，拥有路线图，做架构决定，并在创始人情感上依恋的那个功能其实是个错误赌注时直接告诉他。这种姿态，是主人而非乙方，正是它与 [Fractional CTO](/zh/glossary/fractional-cto/) 的全部区别，后者覆盖技术权威，却不扛产品与所有权的分量。

奥地利的法律细微之处：这是以 freier Dienstvertrag 而非 Werkvertrag 来签约的，因为我们承担的是持续的判断与可用性，而不是一个固定交付物，而且与真正的联合创始人不同，默认没有股权授予，也不进股权表。诚实的取舍，以及创始人会搞错的地方：这不是一个磨工单的人手（要那个就去找承包人），也不是创始人自身信念的替代品。如果你需要的是有人在一份清晰 [SoW](/zh/glossary/sow/) 之下、周日晚上 11 点和你一起坐着啃一个艰难的架构决定，这就是你要的合作形态。已过 PMF、想找的是 CTO？参见 [Fractional CTO 奥地利](/zh/services/fractional-cto/) 。

另见 [CTPO](/zh/glossary/ctpo/) / [CTO](/zh/glossary/cto/) / [Fractional CTO](/zh/glossary/fractional-cto/) / [Fractional CPO](/zh/glossary/fractional-cpo/) / [SoW](/zh/glossary/sow/) / [Product Engineer](/zh/glossary/product-engineer/)

[阅读完整定义 →](/zh/glossary/fractional-cofounder/)

005 / 073 roles [#](#fractional-cto)

按定义好的范围、每周 1 至 3 天为你公司服务的资深技术高管，没有股权也没有全职薪水。

Fractional CTO 这个市场存在，是因为太早请全职 CTO 太贵，太晚请又会致命。一位 fractional [CTO](/zh/glossary/cto/) 弥补中间这段：做架构决定、跑资深工程师的招聘流程、出席董事会，并撰写投资者材料里的技术章节。

举个实际例子：一家种子轮公司有两名能力很强的中级工程师、一位能读代码却无法架构系统的创始人，以及一位在问「为什么路线图老是滑坡」的投资人。他们不需要一位年薪 18 万加股权的全职 CTO。他们需要一个每周两天的人来定架构、为这两名工程师扫清阻碍，并把路线图变成董事会能追踪的里程碑。那就是教科书式的 Fractional CTO 委托，通常会跑六到十二个月，直到能撑起一个全职聘用为止。

他们通常不做的，是写生产代码。如果你的团队需要的是一个强独立贡献者，那你要的是一位资深工程师加上一位 CTO 当思考伙伴，而不是 Fractional CTO 自己亲自做工程。在 Wavect，当团队小到 CTO 也必须发布时，我们偶尔会模糊这条线； [SoW](/zh/glossary/sow/) 会把界线写明确。

奥地利的法律细微之处：Fractional CTO 通常以 Dienstvertrag 或 freier Dienstvertrag 签约，而不是 Werkvertrag，因为他们承担的是持续的判断与可用性，而不是单个固定交付物。这关系到责任归属，也关系到这段合作怎么入账。别让供应商把 Fractional CTO 的 Retainer 包装成固定范围的合同；二者的义务不同。

创始人常犯的错误：把 Fractional CTO 与 [Fractional Co-Founder](/zh/glossary/fractional-cofounder/) 混为一谈。CTO 覆盖技术权威。Co-Founder 的姿态再加上产品策略与所有权行为。如果你想要的是有人挑战你的路线图、而不只是你的技术栈，那你要的是后者。任何 fractional 模式诚实的取舍都是连续性：一个兼职高管永远不会有全职者那样的上下文深度，所以这段合作只在范围有界、且交接从第一天起就规划好时才奏效。

警惕那种把「Fractional CTO」当作客户经理改名来卖的供应商。真正的 Fractional CTO 拥有决策权、出席与全职 CTO 同等的会议，并被写进你的董事会材料里。

另见 [CTO](/zh/glossary/cto/) / [Fractional Co-Founder](/zh/glossary/fractional-cofounder/) / [Fractional CPO](/zh/glossary/fractional-cpo/) / [SoW](/zh/glossary/sow/) / [Retainer 保留费](/zh/glossary/retainer/)

[阅读完整定义 →](/zh/glossary/fractional-cto/)

006 / 073 roles [#](#interim-cto)

亦称: 过渡期 CTO

全职但有期限的 CTO，带领工程团队穿过一段过渡期，通常 3 到 12 个月，直到长期人选接手。

Interim CTO 是一位全职但有期限的高管，在一段过渡期里掌管工程，通常 3 到 12 个月。触发点是一个真空：上一任 CTO 在融资途中辞职了、被解雇了，或者公司在继任计划存在之前就超出了他的能力。Interim 以全负荷进场，稳住组织，再交接给那位常常由他亲自参与招聘的长期人选。

与 [Fractional CTO](/zh/glossary/fractional-cto/) 的区别在承诺形态，不在资历。Fractional 意味着每周 1 到 3 天、持续进行，适合需要 CTO 级别权威、但不需要全职在场的公司。Interim 意味着每周五天、带着计划好的结束日期，适合此刻就有一个全职体量缺口的公司。按缺口的大小来选，而不是按哪个头衔听起来更资深。

举个实际例子：一家扩张期公司在技术尽职调查前八周失去了 CTO。四十名工程师、三个团队、没有副手。一位每周两天的 Fractional 操盘者吸收不了这种局面。这个组织需要有人出现在每一场领导层会议、每一次升级处理、每一通尽调电话里，那就是一份 Interim 委托。镜像的情形，一家只有四名工程师、路线图在滑坡的种子期初创，是一个每周两天的问题。在那里为一位全职 Interim 付费，就是在为没人需要的在场感烧 Runway。

奥地利的法律细微之处与 fractional 模式如出一辙：Interim CTO 通常以 Dienstvertrag 或 freier Dienstvertrag 签约，因为交付的是持续的判断与可用性，而不是一个固定的成果物。Interim 诚实的取舍是那道悬崖：他学到的一切都会在交接时跟着走人，所以委托里必须包含把决定写成文档、并招聘继任者。一位对自己退出计划含糊其词的 Interim 是打算留下来，那是另一种更贵的产品。

Wavect 的合作在设计上就是 fractional 的，每周 1 到 2 天，每段合作都有两位创始人。如果你有一个需要每周五天的真正真空，请一位 Interim，我们会在第一通电话里原话告诉你。两种形态重叠之处，见 [Fractional CTO 奥地利](/zh/services/fractional-cto/) 。

另见 [CTO](/zh/glossary/cto/) / [Fractional CTO](/zh/glossary/fractional-cto/) / [Fractional Co-Founder](/zh/glossary/fractional-cofounder/) / [SoW](/zh/glossary/sow/) / [Retainer 保留费](/zh/glossary/retainer/)

[阅读完整定义 →](/zh/glossary/interim-cto/)

007 / 073 roles [#](#fractional-cpo)

按兼职合同负责路线图与客户发现节奏的资深产品高管，无须全职薪水。

比 [Fractional CTO](/zh/glossary/fractional-cto/) 模式少见，但越来越真实。一位 fractional [CPO](/zh/glossary/cpo/) 每周加入 1 至 3 天，跑产品发现、排序路线图、把握客户访谈节奏。他不负责工程。除非你特别要求，不然也不负责设计。

适配面很窄：公司需要产品上的资深度，但还撑不起全职 CPO 的成本，并且创始人愿意把产品判断权交出来。如果创始人本身就是那个产品的人、且还没准备好分享这份权威，那么 Fractional CPO 就是一个摩擦发生器。

举个实际例子：一家公司已经拿到早期牵引，创始人埋在销售里，工程团队在做上周嗓门最大的客户要的任何东西。一位 Fractional CPO 进来装上一套优先级框架、跑一个像样的发现节奏，并给工程一个排好序的路线图，而不是一堆一次性需求的队列。每周三天就够，因为这份工作是判断和结构，而不是执行的体量。

创始人常犯的错误是在 [PMF](/zh/glossary/pmf/) 之前招一位 Fractional CPO 来回避自己做产品决定。那永远行不通。PMF 之前，创始人对客户的直觉是公司最有价值的单一资产，无法外包。Fractional CPO 扩展的是一个已经有观点的产品职能；它不发明观点。在奥地利，这种合作通常是 freier Dienstvertrag，和大多数 fractional 高管角色一样，因为交付的是持续的判断，而不是一个固定的成果物。

诚实的取舍：一位兼职 CPO 在上下文上永远会落后于全职者，而产品上下文是会复利的。如果你的路线图决定需要每天根据 CPO 不在场的对话来做，那这个模式就崩了。它在「决定可以每周打包、团队能在两次会议之间执行」时才奏效。

相关： [Fractional CPO 奥地利](/zh/services/fractional-cpo/) 和 [Fractional CTO 奥地利](/zh/services/fractional-cto/) 。

另见 [CPO](/zh/glossary/cpo/) / [Fractional Co-Founder](/zh/glossary/fractional-cofounder/) / [Fractional CTO](/zh/glossary/fractional-cto/) / [PMF](/zh/glossary/pmf/) / [MVP](/zh/glossary/mvp/)

[阅读完整定义 →](/zh/glossary/fractional-cpo/)

008 / 073 roles [#](#tech-lead)

亦称: 技术负责人 / TL

团队里最资深的工程师，对团队内部技术决策负责，但不负责更上层的工程组织。

Tech Lead 首先是独立贡献者，其次才是协调者。他写代码。他 Review 代码。两位工程师对实现意见不一致时，他拍板。他不是经理：不处理晋升、绩效评估，也不负责本团队之外的招聘流程。最后这条区分，正是把他和 [Engineering Manager](/zh/glossary/engineering-manager/) 分开的那条线，搞错了它代价很高。

在 Wavect，我们常把 Tech Lead 与一位 fractional [CTO](/zh/glossary/cto/) 一起部署。CTO 负责架构与跨团队协调。Tech Lead 负责本团队日常产出的质量：代码评审标准、团队如何实践 [Agile](/zh/glossary/agile/) 、完成定义是真的还是走过场。把这两个角色混为一谈，是我们在 A 轮初创公司里最常见到的错误。

那个错误，举个实际例子：一家公司把它最好的工程师提拔为「Tech Lead」，然后悄悄堆上 1-on-1、招聘面试和编制规划。半年后代码库因为没有资深的人在评审而漂移，新晋的 Lead 则在把两份工作都做砸的过程中累垮。修法是把分工明确命名出来：技术权威留给 Tech Lead，人事权威移交给一位 EM，哪怕是 fractional 的。

诚实的取舍：一位强 Tech Lead 加上一位外部 CTO 思考伙伴，纸面上往往胜过一位初级全职 CTO，而且便宜得多。天花板是团队之外的决策权。Tech Lead 不负责跨产品的架构，也不负责董事会层面的技术风险，假装他负责，只会推迟你真正需要一位 CTO 的那一刻。

Tech Lead 到底该写多少代码？大多数时间，而这正是创始人悄悄把这个角色弄坏的地方。一旦有人成了「那个 Lead」，本能就是把他拉进会议、规划和协调，直到他每周只写百分之十的代码。一个停止发布的 Tech Lead 会失去团队的技术尊重，并从他本应最深了解的代码库里漂移出去。经验法则是至少一半时间动手，其余花在评审、设计和扫清阻碍上。当协调负荷真正超过这个比例的那一天，你拥有的不是一个超载的 Tech Lead，而是一个没人填的工程管理席位。

相关： [Fractional CTO 奥地利](/zh/services/fractional-cto/) 。

另见 [CTO](/zh/glossary/cto/) / [Engineering Manager](/zh/glossary/engineering-manager/) / [SDLC](/zh/glossary/sdlc/) / [Agile](/zh/glossary/agile/)

[阅读完整定义 →](/zh/glossary/tech-lead/)

009 / 073 roles [#](#engineering-manager)

亦称: EM / 工程经理

面向工程师的人事经理，负责绩效、成长、招聘与团队健康。

工程经理管的是人，不是架构。他们站在工程师与公司其余部分之间：把策略翻译成团队层级的优先级，主导招聘流程，承担没有工程师愿意主动开的对话。技术决定留给 [Tech Lead](/zh/glossary/tech-lead/) ；EM 确保做这些决定的人在成长、被支持、且不会即将离职。

一名好的 EM 具备技术可信度（工程师认可他），同时不会与团队的资深 IC 互相竞争。糟糕的 EM 要么离代码太远而无法带人，要么钻得太深而无法管理。这个角色是最难招的之一；多数早期初创会在技术侧超额招聘、在管理侧招聘不足，于是八人的团队开始摇晃。

举个实际例子：一支团队一年内从五名工程师长到十名。没人补上管理，于是创始 [CTO](/zh/glossary/cto/) 现在一边跑十场 1-on-1、三个招聘流程和两个绩效问题，一边还想扛架构。速度暴跌，两个人离职，所有人都怪「流程」。真正的原因是缺一位 EM。这个信号在离职潮之前几个月就到了：最资深的人花在关于人的会议上的时间，多过花在代码库或 [SDLC](/zh/glossary/sdlc/) 上的时间。

常见的错误是把一位强资深工程师在没有任何培训的情况下提拔进这个角色，并假定人的技能会跟着技术技能自然到来。它们通常不会；这两套技能近乎相互独立。按对人事工作展现出的兴趣来提拔，然后再教技术上下文，而不是反过来。

诚实的取舍：一位出色的 EM 会让团队的产出对创始人变得更不易读，因为他最好的工作（留存、扫清阻碍、艰难对话）不会出现在甘特图上。只衡量已发布功能的创始人，往往会低估并少招这个角色，直到那点摇晃变成离职潮。

相关： [Fractional CTO 奥地利](/zh/services/fractional-cto/) 。

另见 [Tech Lead](/zh/glossary/tech-lead/) / [CTO](/zh/glossary/cto/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/engineering-manager/)

010 / 073 roles [#](#product-manager)

亦称: PM

负责决定构建什么以及为什么构建的人，并要在所有想构建别的东西的人面前捍卫这些决定。

产品经理负责的是「做什么」和「为什么做」，而不是「怎么做」。他决定团队下一步解决哪个问题、为什么这件事重要，以及对客户而言「完成」意味着什么。他不写代码，不以管理者身份运行冲刺，也不设计架构。他的工作是在任何人争论如何把东西做好之前，确保团队正在构建正确的东西。

这个角色主要是在相互冲突的压力下行使判断和沟通。销售想要能促成交易的功能。支持想要修复那个 bug。创始人想要那个大胆的赌注。一个好的产品经理承受这一切，对其中大多数公开说不，并交付那一件能推动业务的事。他对结果负责，这意味着路线图和优先级决策归他所有，而不只是整理待办列表。

产品经理与产品负责人（Product Owner）的区别，是大多数团队搞混的地方。产品负责人是 Scrum 中一个具体的角色，与 [Scrum Master](/zh/glossary/scrum-master/) 不同：它拥有并排序待办列表，让开发团队清楚下一步要构建什么。产品经理是更宽泛的业务角色：市场、战略、定价输入、与利益相关者对齐，以及路线图背后的为什么。一旦组织足够大，它就是那个会向上扩展成 [CPO](/zh/glossary/cpo/) （或一位 [Fractional CPO](/zh/glossary/fractional-cpo/) ）的席位。在小团队里，一个人同时戴这两顶帽子。在更大的团队里，产品经理设定方向，产品负责人把它转化为有序、可直接构建的工作。

常见的错误招聘是招了一个没有权威的产品经理。如果路线图实际上是由嗓门最大的利益相关者决定的，而产品经理只是写工单，那你招的是一个项目协调员，却把它叫作产品。当创始人陷在构建中太深而无法亲自承担时，我们会把产品所有权作为 [兼职联合创始人](/zh/services/fractional-cofounder/) 合作的一部分嵌入创始团队。

另见 [CPO](/zh/glossary/cpo/) / [Fractional CPO](/zh/glossary/fractional-cpo/) / [Tech Lead](/zh/glossary/tech-lead/) / [Scrum Master](/zh/glossary/scrum-master/) / [Product Engineer](/zh/glossary/product-engineer/)

[阅读完整定义 →](/zh/glossary/product-manager/)

011 / 073 roles [#](#product-engineer)

亦称: 产品工程师 / Full-Stack Product Engineer

对结果负责、而不是对工单负责的工程师：他与用户交谈，决定构建什么，并亲自交付。一个人闭合了从问题到代码的整个回路。

产品工程师（Product Engineer）是一名对问题负责、而不仅对实现负责的软件工程师。普通工程师拿到一份规格说明，把它做好。产品工程师会追问这份规格说明是不是该构建的正确东西，会与有这个问题的用户交谈，决定真正要交付什么，然后才写代码。他把 [产品经理](/zh/glossary/product-manager/) 和工程师合并到一个脑袋里。产出不是「按规格说明做出来的功能」，而是「用户的问题，被解决了」。

这个角色之所以存在，是因为产品死在交接处。产品经理写一份规格说明，工程师严格照做，三周后却没人用这个功能，因为规格说明漏掉了一个只有盯着代码的人、或用户本人才会发现的细节。产品工程师在构建途中就能抓住它，因为两端都归他。按定义，他并不比普通工程师更资深。他的接线方式不同：他在意的是指标动起来，而不是工单被关掉。

一个说明为何融合更胜一筹的具体例子：某 SaaS 团队完全按设计交付了一套引导流程。激活率纹丝不动。产品经理怪构建，工程怪规格说明，等到有人去验证真正的假设时，一个月已经没了。换成产品工程师，他会在三天内交付一个更薄的版本，看着五个真实用户卡在第二步，并在冲刺结束前重写第二步。同样的人手，十分之一的周期时间，因为既没有交接，也没有甩锅回路。从「用户卡住了」到「在生产环境修好了」的路径，全在一个脑袋里跑完。

这正是 Wavect 实际工作中很大一部分内容。我们大多数的 [兼职联合创始人](/zh/services/fractional-cofounder/) 和 [CTPO](/zh/glossary/ctpo/) 合作，本质上就是换了名字的产品工程：一个操盘者负责界定 [MVP](/zh/glossary/mvp/) 、与你的用户交谈、交付代码，而不是一个产品经理、一个设计师加三个承包商在玩传话游戏。诚实的取舍：产品工程师很难招，而且无法线性扩展。你无法在一个产品上堆二十个，而现有的那些人很贵，因为这种组合很稀有。创始人常犯的错误是招了一个对用户毫无兴趣的出色程序员，然后纳闷为什么路线图里全是没人要的优雅功能。解法不是在上面再加一层更厚的产品经理，而是一个宁愿和客户聊天、也不愿去调构建流水线的工程师。相关： [定制软件开发](/zh/services/software-development/) 。

另见 [Product Manager](/zh/glossary/product-manager/) / [CTPO](/zh/glossary/ctpo/) / [Fractional Co-Founder](/zh/glossary/fractional-cofounder/) / [MVP](/zh/glossary/mvp/) / [Software Architect](/zh/glossary/software-architect/)

[阅读完整定义 →](/zh/glossary/product-engineer/)

012 / 073 roles [#](#software-architect)

亦称: Solutions Architect

负责软件系统级形态的人：那些难以逆转、代价高昂的重大结构性决策，以及无人认领的非功能性需求。

软件架构师负责那些难以撤销的决策。系统如何拆分成服务或模块、数据如何在其中流动、边界设在何处、技术栈承诺采用哪些技术，以及整体在负载、故障和增长下如何撑住。单个功能改起来很便宜。这些结构性选择则不然，因此需要有人在系统层面而非功能层面思考。

真正的价值在于非功能性需求：性能、可扩展性、安全性、可靠性、可维护性。这些都是没有任何单个功能工单认领、一旦被忽视就会悄悄拖垮产品的东西。架构师的工作是把权衡公开说出来。现在构建更快，还是以后修改更便宜。简单而有限，还是灵活而复杂。没有免费的架构，只有你有意选择的权衡，或你因意外而继承的权衡。

大多数初创公司不需要专职软件架构师，过早招一个通常是个错误。在小规模时架构很小， [技术负责人](/zh/glossary/tech-lead/) 或 [CTO](/zh/glossary/cto/) 会把它作为本职工作的一部分承担起来。一个全职的架构师，没有代码可写，也没有团队可带，往往只会产出团队随后就忽略的图表和标准文档。只有当系统大到没有人能在脑中装下整幅图景时，这个角色才值回它的位置。

为什么不写代码的架构师会跑偏，举个实际例子：一位两年前就离开了代码库的架构师，设计了一套「干净的」事件驱动系统，配六个队列和三个数据库，因为在白板上这把一切都解耦得很漂亮。而要去构建它的团队发现，本地开发环境现在要花一天才搭得起来，每个功能都要触及四个服务，调试一个用户投诉意味着在所有这些服务之间关联日志。图很优雅；亲历的体验是受罪。一位仍然贴近代码的架构师会预先感受到那份代价，因为正是他得在自己的笔记本上跑那六个队列。

诚实的看法：供应商组织架构图上的「解决方案架构师」往往意味着一个售前角色，设计他永远不必维护的系统。一个好的架构师会离代码足够近，以便感受到自己决策的后果。如果画方框的人永远不必住进那些方框里，那些方框就会画错。

**在软件项目中何时最关键。** 一旦系统大到没人能把整张图装进脑子里。那些结构性决策，服务边界、数据流、技术栈的承诺，正是难以逆转的，所以需要系统层面的思考。

**创始人通常会搞错什么。** 他们太早雇一个专职架构师。在小规模下架构本就小，由 tech lead 或 CTO 顺带扛着；一个没有代码可写的全职架构师，往往产出团队随后会无视的图表。

**Wavect 如何处理。** 我们的架构师离代码足够近，以便感受到自己决策的后果，这正是关键。早早选对结构从技术栈开始， [如何为 MVP 选择技术栈](/zh/software-development-guide/how-to-choose-a-tech-stack-for-mvp/) 对此有讲解。

另见 [Tech Lead](/zh/glossary/tech-lead/) / [CTO](/zh/glossary/cto/) / [Engineering Manager](/zh/glossary/engineering-manager/)

[阅读完整定义 →](/zh/glossary/software-architect/)

013 / 073 roles [#](#scrum-master)

其工作是清除障碍、保护团队免受干扰并让流程持续运转的人，而不是管理人员或分派工作。

Scrum Master 只有一项真正的工作：通过为团队扫清障碍来让团队更高效。这意味着清除阻塞、在冲刺中途为团队挡掉干扰、主持站会和回顾会使其有用而非走过场，以及指导团队如何真正地工作，而不只是背诵那些仪式。他是团队的服务者，而不是团队之上的老板。他不分派工作，不拥有待办列表，也不做绩效评估。

这个角色会在两个方向上被误解。有人把它当作一个升级版的会议安排员，照着站会脚本念。另一些人则悄悄把它变成一个项目经理，逼团队对日期做出承诺。两者都没抓住要点。价值在于察觉是什么在拖慢团队，往往是某件组织层面的、令人不适的事，并且有足够的分量去解决它。一个只主持会议的 Scrum Master 是开销。

诚实的看法：小团队很少需要一个全职的 Scrum Master。一个四五人的工程团队可以自己运行那些仪式，而主持工作每周只需几个小时，技术负责人或资深工程师就能吸收。专职全职的 Scrum Master 在以下情况才值回座位：你在协调多个团队、团队周围的组织是阻塞的主要来源，或一个团队确实还无法自我组织。在此之下，这个头衔是一笔在寻找正当理由的成本。

我们见过许多团队在裁掉全职 Scrum Master、把工作分摊回团队之后变得更开心、更快。我们也见过团队因为无人认领阻塞而溺水。这个角色是真实的，全职版本则往往不是。

另见 [Scrum](/zh/glossary/scrum/) / [Agile](/zh/glossary/agile/) / [Engineering Manager](/zh/glossary/engineering-manager/) / [Product Manager](/zh/glossary/product-manager/)

[阅读完整定义 →](/zh/glossary/scrum-master/)

## 合作与合同模式

合作模式 · 15

合同的不同形态。每一种都把风险推向桌子上的另一侧。

014 / 073 engagement [#](#cto-as-a-service)

亦称: CTOaaS

一种订阅形态的合作，卖的是 CTO 级别的决策权，而不在工资单上放一位全职高管。和 Fractional CTO 是同一份工作，不同的包装。

CTO as a Service 是一个包装用的标签，不是另一份工作。在这个标签下，供应商把 CTO 级别的判断力（架构决策、招聘流程、供应商管理、董事会级别的汇报）当作一项有固定时间投入的循环服务来卖。剥掉品牌包装，剩下的就是一位按 [Retainer](/zh/glossary/retainer/) 工作的 [Fractional CTO](/zh/glossary/fractional-cto/) ：同样的权威，同样的会议，用一份订阅代替一份薪水。

这个标签之所以要紧，在于它能藏住什么。「as a Service」暗示这个人是可替换的，而 CTO 的工作是一家公司买到的最不可替换的工作。上下文是会复利的：第一个月做出的架构决定，只有亲眼看着各种取舍在第四个月落地的那个人才真正理解。在服务品牌背后轮换顾问的供应商，每轮换一次就把这份上下文清零一次，而每一次重新入职的成本都由客户来付。

失败模式举个实际例子：一家初创和某家机构签了一个 CTO-as-a-Service 套餐。第一个月来的是一位资深架构师。到第三个月，每周例会由一位客户经理主持，他把问题转达给一个顾问池。这家初创仍然按高管费率付费，但房间里没有任何人能在不向上请示的情况下对一个功能说「不」。那是贴了 CTO 标签的客户管理，也是把创始人从这个品类带到我们这里的最常见的那条抱怨。

签字前要查什么：到底是谁来（写进合同的具名人选，不是一个池子）、他是否握有决策权还是要上报给一个你永远见不到的人，以及这段合作怎么结束（一份交接计划，不是一场续约推销）。在奥地利，这通常是 Dienstvertrag 式的 Retainer 而不是 Werkvertrag，因为交付的是持续的判断，而一条干净的按周或按月取消条款，才是「as a Service」的诚实版本。

Wavect 的版本是 [Fractional CTO 奥地利](/zh/services/fractional-cto/) 合作：CTO-on-Call 每月 2,500 欧元起，或嵌入式操盘者每周 1 到 2 天，每段合作都有两位具名创始人，任何一周都可取消。

另见 [Fractional CTO](/zh/glossary/fractional-cto/) / [Interim CTO](/zh/glossary/interim-cto/) / [CTO](/zh/glossary/cto/) / [Retainer 保留费](/zh/glossary/retainer/) / [SoW](/zh/glossary/sow/)

[阅读完整定义 →](/zh/glossary/cto-as-a-service/)

015 / 073 engagement [#](#sow)

亦称: Statement of Work / Werkvertrag / 工作说明书

一份签署过的合同，明确指出交付物、价格与截止日期，并在法律上把供应商绑定到这三项之上。

SoW 是把口头约定变成合同的那份文件。它以具体语言列出交付物（例如「功能 X 上线到生产，通过验收标准 A、B、C」）、价格、截止日期与签收条件。

在奥地利与德国法律下，对应的工具是 Werkvertrag，它比英语世界的 SoW 更强：供应商在法律上必须交付这项工作，而不仅仅是提供劳动，客户可以在工作被验收之前扣留付款。同一法律框架下的 [Time & Material](/zh/glossary/time-and-material/) 合同是 Dienstvertrag，只承担劳动义务。Wavect 的 [固定价格](/zh/glossary/fixed-price/) 合作都是 Werkvertrag 合同。

为什么验收标准撑起了整份合同，举个实际例子：一份写着「构建报表功能，功能应当运作良好」的 SoW 无法执行，因为「运作良好」是个意见。一份写着「端点 /reports 在负载 L 下、对输入区间 R 在 200ms 内返回月度数字，且数值匹配规格 S」的 SoW 可被测试，「做完了」不再是一场谈判。创始人最常犯的错误是为了在开头省时间而签一份措辞含糊的 SoW，然后花六个月争论一个半成品功能算不算交付了。一个抗拒写下精确验收标准的供应商，是在保护他将来去吵这场架的权利。

SoW 同时也是防止范围蔓延的文件：任何不在其中的内容，按定义就在范围之外，要用 Change Request 处理。注意分层，一份 MSA（主服务协议）一次性覆盖法律框架（知识产权、责任、管辖），而多份 SoW 可以随时间挂在它之下。诚实的取舍是，一份严密的 SoW 要花真功夫去写，前期感觉很慢，而这恰恰是一段付费的 [发现阶段](/zh/glossary/discovery-phase/) 存在的意义。相关： [Fractional CTO 奥地利](/zh/services/fractional-cto/) 解释了 Werkvertrag 模式的实操。

**在软件项目中何时最关键。** 在钱易手的那一刻。SoW 是「你买的是什么」从一场对话变成可强制执行条款的地方，所以它是唯一一份决定日后争议是按合同解决、还是按谁嗓门大解决的文件。

**创始人通常会搞错什么。** 他们为了更快开工而签下一份措辞含糊的 SoW，然后花几个月争论一个半成品功能算不算交付。验收标准承载了整份合同；「应该好用」是一种意见，不是交付物。

**Wavect 如何处理。** 我们在任何人签字之前就把验收标准写得足够精确、可测试，并先跑一段付费 Discovery，让范围是真实的。我们的 [如何挑选软件机构指南](/zh/software-development-guide/how-to-choose-a-software-agency/) 和 [固定价格对比 Time and Materials 指南](/zh/software-development-guide/fixed-price-vs-time-and-materials/) 用大白话讲透了合同决策。

另见 [固定价格](/zh/glossary/fixed-price/) / [Time & Material](/zh/glossary/time-and-material/) / [Retainer 保留费](/zh/glossary/retainer/) / [Discovery Phase 发现阶段](/zh/glossary/discovery-phase/)

[阅读完整定义 →](/zh/glossary/sow/)

016 / 073 engagement [#](#time-and-material)

亦称: T&M / 按工时计费

你为投入的工时付费，而不是为交付的成果付费。供应商不承担交付风险；风险全在你这边。

Time & Material 是 Staffing Agency 与多数 Freelance 合同的默认模式。你按小时或按天付费；供应商记录工时；账单按月来。合同里没有「交付物」这件东西，只有「合同约定的投入」。在奥地利与德国法律下，这对应 Dienstvertrag：供应商承担的是努力与勤勉，而不是一个完成的成果物。那个法律区分就是全部要害，也正是为什么一份 [SoW](/zh/glossary/sow/) （即 Werkvertrag）是一种根本不同的工具，而不只是另一种开账单的方式。

这种模式在「没人假装供应商对结果负责」这一点上是诚实的。它也是常见合作模式中激励对齐最差的：供应商的动机是多记工时，而不是更快做完。聪明的客户会给 T&M 加上预算上限和清晰范围，本质上是在没有法律牙齿的情况下把一份 [固定价格](/zh/glossary/fixed-price/) 合作重新发明一遍。

T&M 怎么走偏，举个实际例子：一位创始人为一个大家早已谈妥的功能签了一份「用 T&M 保持灵活」的合同。三个月和四万欧元之后它完成了七成，外包提议再加六周，而创始人没有任何合同杠杆可拉，因为他从没命名一个交付物。同样的工作要是按 Werkvertrag 来定范围，那个「完成七成」的问题就该由供应商在供应商自己的成本上去解决。

Wavect 在范围真的无法事先定义的探索性项目里才用 T&M。我们不把它当默认。诚实的取舍是真实的：对开放式研究或不可预测的维护，T&M 确实是正确的模式，强加一个固定范围只会让我们虚报估算或为「做完了」争吵。经验法则是：当还没人能描述交付物时用 T&M，一旦能描述了就立刻切到 [Retainer](/zh/glossary/retainer/) 或一份 SoW。如果一个供应商把有明确交付物的工作往 T&M 上推，他就是在把风险塞给你。

**在软件项目中何时最关键。** 每当供应商对一项大家已经谈妥的工作提议按小时计费时。那正是交付风险悄悄从供应商转到你身上的点，多数创始人直到账单跑过产出才察觉。

**创始人通常会搞错什么。** 他们为了「保持灵活」而对一个从不真正不确定的功能选了 T&M。三个月、一张五位数账单之后，它做到 70%，他们却没有合同杠杆，因为从未命名过交付物。

**Wavect 如何处理。** 我们只对真正开放式的工作用 T&M，并用预算上限和每周燃尽来设限。 [固定价格对比 Time and Materials 指南](/zh/software-development-guide/fixed-price-vs-time-and-materials/) 讲清了每种模式在什么时候才是诚实的选择。

另见 [SoW](/zh/glossary/sow/) / [固定价格](/zh/glossary/fixed-price/) / [Retainer 保留费](/zh/glossary/retainer/)

[阅读完整定义 →](/zh/glossary/time-and-material/)

017 / 073 engagement [#](#fixed-price)

亦称: Fixed-Price / Fixed Scope

签署过的 SoW（在奥/德为 Werkvertrag）。供应商在法律上必须按约定的范围、价格与截止日期交付。

固定价格合作把交付风险从客户转移到供应商。开工前价格已定。范围已书面写明。截止日期是合同的一部分。供应商超出预算或时间，那是供应商的问题，不是你的。

要让这一切是真的而不是表演，合同必须是 Werkvertrag（奥/德法律下）或当地最接近的等价物。Werkvertrag 在法律上把供应商绑定到交付这项工作，而不仅仅是提供劳动，客户可以在工作被验收前扣留付款。「固定价格」只是一句口头承诺、底层却垫着一份 [Time & Material](/zh/glossary/time-and-material/) 合同，那不是固定价格，那是一句营销话术。背后的那份 [SoW](/zh/glossary/sow/) 才是这个保证真正存活或死亡的地方。

举个实际例子：一个供应商报价「大约两万五，固定」，但 SoW 写着「按工时按月付款」，且没有列出任何验收标准。那是 T&M 戴了顶固定价格的帽子。诚实的版本会命名交付物（「结账流程上线，通过验收测试 A、B、C，截止日期 X」），写明价格，并把超支风险压在供应商身上。如果他们不肯把这些写下来，那价格就不是固定的。

Wavect 在范围明确、且发现工作已经做过的项目上跑固定价格。对发现之前的工作，我们先跑一个 2 至 3 周的 [发现阶段](/zh/glossary/discovery-phase/) ，它本身也是固定价格。如果你继续与我们做 Build，这笔费用会从 Build 发票里扣除。

诚实的取舍，以及创始人最常犯的错误：把固定价格强加到真正不确定的范围上。当未知很大时，固定价格供应商要么把估算虚报 30% 到 100% 来吸收风险，要么报低再砍质量来守住预算。两者都不利于你。先做发现，对你真正知道的部分固定价格，把真正未知的部分放在另一种模式上。Wavect 的固定价格保证意思是：签署过的 SoW（Werkvertrag），法律上必须交付。它不等于「错过截止日期就退款」。

相关： [Fractional CTO 奥地利](/zh/services/fractional-cto/) 公开了每个档位的固定价格。

**在软件项目中何时最关键。** 当范围已锁定、而你希望交付风险落在供应商而非你身上时。固定价格只有在未知项被解决之后才诚实，通常要靠 Discovery。

**创始人通常会搞错什么。** 他们为了封顶预算，把固定价格强加到真正不确定的范围上。供应商于是把估算抬高 30% 到 100% 来吸收风险，或低报后再砍质量来不超支。两者都不为你服务，而固定价格保证是「交付已签范围」的承诺，不是日期滑动就退款。

**Wavect 如何处理。** 我们只对 Discovery 真正定下来的部分锁价，签一份 Werkvertrag，把超支风险压在我们身上。 [固定价格对比 Time and Materials 指南](/zh/software-development-guide/fixed-price-vs-time-and-materials/) 讲清了何时锁价、何时保持灵活。

另见 [SoW](/zh/glossary/sow/) / [Time & Material](/zh/glossary/time-and-material/) / [Discovery Phase 发现阶段](/zh/glossary/discovery-phase/) / [Retainer 保留费](/zh/glossary/retainer/)

[阅读完整定义 →](/zh/glossary/fixed-price/)

018 / 073 engagement [#](#retainer)

按月循环的合作形式，供应商预留约定的容量，客户按月支付可预测的费用。

Retainer 是对供应商时间的订阅。你每月付款；作为回报，你得到约定的天数或约定的团队容量。具体范围会变；可用性不会变。

当工作是持续的、且优先级变化太快、 [SoW](/zh/glossary/sow/) 跟不上时，Retainer 很好用。产品团队用 Retainer 请设计合作伙伴，工程团队用它聘 fractional 资深角色，几乎每一份法律顾问安排都是 Retainer。在奥地利，Retainer 通常被构造成 Dienstvertrag 或 freier Dienstvertrag，因为你买的是被预留的可用性与判断，而不是一个固定成果物。

风险与 [T&M](/zh/glossary/time-and-material/) 相反：没有活的时候供应商也照拿钱。聪明的客户会附上一条「合理使用」条款，并每季度复盘 Retainer 以确认容量在被使用。如果利用率低于 60%，说明 Retainer 形态不对，你要的是一份按次的 SoW。

举个实际例子：一家初创公司「为了保险起见」把一位资深顾问放在每月 10 天的 Retainer 上。头两个月被用满；然后产品上线、工作量掉到每月两天，但发票没掉。他们现在为八个闲置的天数付费。修法不是取消这段关系，而是把它调到合身：降到一个更小的 Retainer，再加上在真正出现交付物时去定一个 [固定价格](/zh/glossary/fixed-price/) Build 的选项。健康的 Retainer 坐落在 70% 到 85% 的利用率；低于这个你买的是保险，高于 95% 你是在把供应商当员工使，留给真正要紧的工作的余量为零。

诚实的取舍是可预测性对效率。Retainer 给你一个已知的月度成本和一颗被预留的资深大脑，代价是在安静的月份里为容量付费。相关： [Fractional CTO 奥地利](/zh/services/fractional-cto/) 跑的是一个你每周都能取消的周度 [Retainer](/zh/glossary/fractional-cofounder/) ，这去掉了让传统 Retainer 有风险的大部分锁定。

另见 [SoW](/zh/glossary/sow/) / [Time & Material](/zh/glossary/time-and-material/) / [固定价格](/zh/glossary/fixed-price/) / [Fractional Co-Founder](/zh/glossary/fractional-cofounder/)

[阅读完整定义 →](/zh/glossary/retainer/)

019 / 073 engagement [#](#discovery-phase)

短期固定价格合作（Wavect：2 至 3 周，3,500 欧元），结束时交付签署过的架构、里程碑计划与固定价格的 Build 报价。

Discovery 是「能诚实报出一个 [固定价格](/zh/glossary/fixed-price/) Build」之前必须发生的工作。它产出四个成果物：一份软件架构、一份里程碑计划、关键技术流程，以及一份上线计划。基于这些，供应商才能报出一个真实的固定价格，并写出一份站得住脚的 [SoW](/zh/glossary/sow/) 。

Wavect 把 Discovery 作为一个 2 至 3 周、3,500 欧元的固定价格项目来跑。如果你继续与我们做 Build，Discovery 费用从第一张发票里扣除。如果不继续，你保留全部四份成果物，可以拿给另一个供应商。最后这一点是诚实 Discovery 的试金石：即便你掉头走开，产出也应当有用。

为什么这要紧，举个实际例子：一位创始人为同一个应用收集了三份「免费」报价，得到三万、七万和十一万。这个差距不是供应商贪婪，而是没有一个真正给工作定了范围，于是每个都为各自想象出来的一套未知做了溢价。一段付费的 Discovery 用一份架构和一份里程碑计划替换掉这些猜测，从而抹平这个差距，而这也正是一段诚实的 [SDLC](/zh/glossary/sdlc/) 的起点。同样这些成果物，让你能分辨出一个八周就能发布的 [MVP](/zh/glossary/mvp/) 和一个你正悄悄为之承诺一整年的平台。

我们为什么对 Discovery 收费：免费的范围评估要么不诚实（供应商在 Build 估算里把成本收回来），要么质量低（供应商赶工，因为它没付钱）。收费修正了激励。诚实的取舍是，Discovery 感觉像是在你还没有任何东西可展示之前就花钱。你确实有东西：这四份成果物是一项可携带的资产，而另一种选择（在没人定过范围的 Build 上承诺六位数）才是昂贵的那个，不是便宜的那个。

相关： [Fractional CTO 奥地利](/zh/services/fractional-cto/) 把 Discovery 列为四个价格档位之一。

**在软件项目中何时最关键。** 在你把构建预算押在一个还无法精确描述的东西之前。Discovery 是发现「你正要造错东西」的最便宜的地方，因为每一个被跳过的错误假设都会被烧进代码、日后才偿还。

**创始人通常会搞错什么。** 他们收三份「免费」报价，拿到差距巨大的数字，就把这个区间当成供应商的贪婪。区间其实是因为没人给工作定过范围，于是每家都为一套各自想象的未知项虚报。为省几周而跳过 Discovery，常常要赔上几个月的返工。

**Wavect 如何处理。** 我们把 Discovery 当成一段短的固定价格项目来跑，结束时交付一份可移植的架构、里程碑计划和可报价的范围，即便你离开也用得上。见 [什么是发现阶段](/zh/software-development-guide/what-is-a-discovery-phase/) 和 [如何为 MVP 选择技术栈](/zh/software-development-guide/how-to-choose-a-tech-stack-for-mvp/) 。

另见 [SoW](/zh/glossary/sow/) / [固定价格](/zh/glossary/fixed-price/) / [MVP](/zh/glossary/mvp/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/discovery-phase/)

020 / 073 engagement [#](#sprint)

固定长度的工作单元（通常 1 至 2 周），结束时交付并复盘一个可发布的增量。

Sprint 原本是 Scrum 专有的术语，后来渗进日常用语，泛指任何短的、时间盒式的工作单元。原始定义要求三件事：一个固定长度、开头的一次计划会议、结尾的一次评审。多数团队保留前两个、去掉了第三个，所以很多团队把节奏叫「Sprint」，却产不出可演示的增量。没有演示的 Sprint 只是一个截止日期；没有回顾的 Sprint 是一台跑步机。

时长很重要。一周 Sprint 强迫范围收紧，能很快暴露交付问题。两周 Sprint 留出做实质工作的空间，但吸收更多偏移。三周 Sprint 几乎一定会变成两个糟糕计划的 Sprint。

沉默的失败，举个实际例子：一支团队跑了六个月的两周「Sprint」，每场计划会议都开了，却没发布出任何一个利益相关者能点击的东西。董事会不断滑坡，因为工作是按希望来估的、而不是按装得下的来估，而且没有一次评审强迫团队去直面一个可运行的增量。修法既残酷又简单：每个 Sprint 结束时，团队之外的某个人必须能用上造出来的东西。如果他用不了，那这个节奏就是表演，缩到一周 Sprint 通常会在两周内暴露出原因。

诚实的取舍与创始人最常犯的错误：把 Sprint 当成命中一个固定外部截止日期的方式。这个节奏是围绕「固定时间盒、浮动范围」来构建的，恰恰与「硬上线日期加固定范围」相反。对真正由日期驱动、范围固定的工作，你要的是一份带明确 [SDLC](/zh/glossary/sdlc/) 里程碑的固定价格计划，而不是一块 Sprint 看板。Sprint 适合持续的 [Agile](/zh/glossary/agile/) 交付和朝 [MVP](/zh/glossary/mvp/) 的迭代工作；它不太适合研究和设计工作，那种场景下一段带书面总结的时间盒探索胜过一次被强加的演示。它们还依赖 [CI/CD](/zh/glossary/ci-cd/) 的健康，因为一个在结束时无法发布的 Sprint 不是 Sprint。

**在软件项目中何时最关键。** 每当你购买的是持续、迭代的交付，并且想以稳定节奏看到能运行的软件，而不是在最后来一次大揭幕时。

**创始人通常会搞错什么。** 他们把 Sprint 当成命中一个固定外部上线日期的方式，这恰恰相反：节奏是固定时间盒、浮动范围。他们还会丢掉演示和复盘，于是开了一堆计划会议，却交付不出任何利益相关者能点击的东西。

**Wavect 如何处理。** 我们保留演示和复盘，每个 Sprint 结束时的标尺是：团队之外的人能用上一个可运行的增量。对真正由日期驱动、范围固定的工作，我们改为按明确里程碑来规划，正如 [上线前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 所述。

另见 [Agile](/zh/glossary/agile/) / [MVP](/zh/glossary/mvp/) / [CI/CD](/zh/glossary/ci-cd/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/sprint/)

021 / 073 engagement [#](#staff-augmentation)

你把外部工程师招入自己的团队，在你的管理下、按你的路线图工作。供应商提供人，你提供方向。

人员扩充（staff augmentation）就是把外部工程师加入你现有的团队。他们参加你的站会、处理你的待办事项、遵循你的流程。管理权、架构决策和责任都留在你手里。供应商提供人手并按时间计费。整个模式就是这样。

当你拥有一个能运转的团队和一个能运转的计划，只是在一段已知的工作期内需要更多人动手时，它就合适。它几乎总是按 [Time & Material](/zh/glossary/time-and-material/) 计费，所以交付风险落在你身上。当你还不知道要构建什么、当内部没有人能指挥这些新工程师、或者当你需要有人对一个结果负责而不是执行一张工单时，它就不合适。要让人对结果负责，你需要的是 [专属团队](/zh/glossary/dedicated-team/) 或一个 fractional 资深角色，而不是人员扩充。

没人会把资深度陷阱写进宣传册。大多数人员扩充供应商打着资深档案的旗号，却给你安排初级工程师，他们需要和你自己的初级员工一样多的手把手指导，只是现在你要为这份特权支付代理机构的费率。你承担管理开销，供应商不承担任何交付风险。请阅读具名简历、面试真实的那个人，并在合同里写入替换条款。

有一条值得点出的奥地利法律细节：人员扩充可能滑向 Arbeitskräfteüberlassung（劳动力派遣），那是一种受监管的安排，对谁来指挥这名工人、以及如何对待他，有其自身的义务。如果一名「扩充」的工程师在你的指挥下长期完全嵌入，这段关系在法律上看起来可能更像派遣劳动，而不是一份服务合同，对双方都有后果。对短期、范围明确的合作，这很少成为问题，但与其在审计时才发现分类有误，不如一开始就把合同形态弄对。

Wavect 不经营人力中介。我们只有资深操盘者，所以当我们坐进你的团队时，干活的是 [软件开发](/zh/services/software-development/) 页面上的那个人，而不是名单上某个会在第三周被悄悄替换掉的名字。

**在软件项目中何时最关键。** 当你已经有一个能运转的团队和一份能运转的计划，只是需要为一段已知的工作多几双手时。你保留管理、架构和责任；供应商提供人。

**创始人通常会搞错什么。** 他们买进被宣传的资深档案，拿到的却是需要和自家初级一样多照看的初级，只是收着机构费率，而供应商不担交付风险。当没人能在内部真正指挥这些新工程师时，他们也会去求助人力补充。

**Wavect 如何处理。** 我们只配资深，第三周不会有悄悄替换。如果你要的是有人对结果负责、而非执行工单，我们会直说。 [如何挑选软件机构](/zh/software-development-guide/how-to-choose-a-software-agency/) 和 [自由职业者对比机构对比自建团队](/zh/software-development-guide/freelancer-vs-agency-vs-in-house/) 两份指南帮你选对模式。

另见 [Dedicated Team](/zh/glossary/dedicated-team/) / [Time & Material](/zh/glossary/time-and-material/) / [Retainer 保留费](/zh/glossary/retainer/) / [Nearshoring](/zh/glossary/nearshoring/)

[阅读完整定义 →](/zh/glossary/staff-augmentation/)

022 / 073 engagement [#](#technical-due-diligence)

亦称: Tech DD / Technical DD

投资人或收购方在一轮融资或收购之前付费进行的独立技术评估：代码、架构、团队、安全、可扩展性以及关键人员风险。

技术尽职调查是严肃的投资人或收购方在资金易主之前委托进行的工作。它回答一个直白的问题：技术是否真的支撑得起这个估值，还是故事讲得比代码库更好。一次到位的评审会涵盖代码质量与可维护性、架构以及它能否扩展到下一个数量级、安全态势、测试套件与交付流水线的状态、团队的真实深度，以及藏在某位创始人脑子里的关键人员风险。

对买方而言，技术尽调就是给风险定价。你找的不是完美的代码；这个阶段的每家公司都有债务，也都有一套粗糙的 [SDLC](/zh/glossary/sdlc/) 。你找的是路演稿声称的内容与代码仓库展示的内容之间的差距，以及那些会在交易完成后变成紧急事件的地雷：只有一个工程师知道一切如何运作、一个会毒化商业产品的许可证、一个合规漏洞、一个无法挺过你正在为之付费的增长的架构。

对卖方而言，在那个房间替你做之前先做好自己的技术尽调，是保护估值最便宜的方式之一。尽调期间的意外会消耗你的谈判筹码；而你已经理解并已备好计划的发现则不会。做了前置评审的创始人走进资料室时带的是答案，而不是解释。

一个能撼动整笔交易的单条发现，举个实际例子：买方的评审员发现，整个支付与对账核心是由一名八个月前已经离职的工程师独自写的，没有文档，也没有测试。那不是一条代码质量的脚注；那是关键人员风险，收购方会把它定价为一笔折扣或一份保留款，因为那个模块哪天一出问题，公司现有的人没有一个能有把握地修。一位做过自查的创始人本会预见到这一点，要么把这个模块写好文档、要么花钱让第二名工程师把它学会、要么至少带着一份可信的整改计划走进那个房间。同样这条发现，由买方而非由你先抛出来，就会在条款清单上真金白银地让你付出代价。

Wavect 以资深操盘者的身份做技术尽职调查，而不是照清单核对的审计员，这正是我们带进一段付费 [发现阶段](/zh/glossary/discovery-phase/) 的同一种姿态。我们在谈判桌两侧都做过，包括数据密集型和受监管的平台，并且写出的发现能让非技术董事会据以行动。它与我们的 [Fractional Co-Founder](/zh/services/fractional-cofounder/) 工作以及 [Fractional CTO](/zh/glossary/fractional-cto/) 委托天然契合，评估风险的同一个人也能帮你修复它。

**在软件项目中何时最关键。** 在钱易手之前，无论是一轮融资还是一次收购的哪一侧。那个直白的问题是：技术究竟支撑得起这个估值，还是故事讲得比代码库好。

**创始人通常会搞错什么。** 在卖方一侧，他们带着解释而非答案走进数据室。买方挖出的一个发现，一个由单个工程师写的无文档模块、一张毒化商业产品的许可证，会在条款清单上花掉真金白银；而同一个发现若由你先挖出来，则一分不花。

**Wavect 如何处理。** 我们以资深操盘者的身份审查，而非照清单核对的审计员，写出非技术董事会能据以行动的发现。同一种严谨驱动着我们的付费 Discovery，所以 [如何挑选软件机构指南](/zh/software-development-guide/how-to-choose-a-software-agency/) 是判断一个构建团队真实深度的好入门。

另见 [Discovery Phase 发现阶段](/zh/glossary/discovery-phase/) / [Fractional CTO](/zh/glossary/fractional-cto/) / [CTO](/zh/glossary/cto/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/technical-due-diligence/)

023 / 073 engagement [#](#proof-of-concept)

亦称: PoC

一个用完即弃的构建，只回答一个问题：这在技术上可行吗。它不是产品、不是 MVP、也不是你交付给用户的东西。

概念验证存在的目的是消除一个特定的技术风险。这个模型能否达到我们需要的延迟。这个集成对接旧系统时是否真的能跑通。在围绕它设计产品之前，我们能否先证明这套密码学。一个 PoC 只回答「这可行吗」，别的什么都不回答。它被快速构建，按能否运作来评判，然后被丢弃。

让公司付出最大代价的区别是 PoC、MVP 与原型之间的区别。PoC 回答「这在技术上可行吗」，面向你自己的团队。原型回答「这感觉对不对」，面向设计与可用性，通常根本没有真正的后端。 [MVP](/zh/glossary/mvp/) 回答「到底有没有人会使用并为之付费」，它是一个真正的产品，交付给真实用户，只是裁剪成值得他们花时间的最小版本。它们有不同的受众、不同的质量门槛、不同的完成定义，而这种区别直接对应于你相对 [PMF](/zh/glossary/pmf/) 处在哪个位置。

常见且昂贵的错误是把 PoC 当作生产环境去交付。那段证明某件事可行的代码，是为了证明某件事可行而写的：没有错误处理、没有测试、没有安全评审、到处都是捷径。当演示打动了某个人、于是决定「直接上线」时，你就把所有这些当作地基继承了下来。诚实的做法是把 PoC 当作一个问题的答案，然后把真正的东西好好地构建出来。

有一个办法能让这份纪律在压力下也守得住：在开始之前就写下这个 PoC 要回答的那一个问题，以及判定「是」或「否」的标准。「这个模型能不能在我们最近的 500 张工单上以 90% 的准确率给工单分类」就是一个有明确裁决的问题。没有这个写下来的问题，一个 PoC 会悄悄变异成一个半成品，团队因为它「差不多能跑」就一直打磨它，于是你在没有任何人做出决定的情况下，滑进了在用完即弃的地基上构建 V1。这个写下来的问题，也是保护你不被沉没成本拽着去上线那段废弃代码的东西：一旦问题被回答，PoC 就完成了它的使命、值得被删掉，无论那个演示看起来多漂亮。

当存在真正值得在投入构建之前消除的技术风险时，Wavect 才做 PoC。大多数项目并不需要它；它们需要的是一个为工作划定范围的 [发现阶段](/zh/glossary/discovery-phase/) 。我们会告诉你你面对的是哪一种。如果问题是商业选择而不是术语定义，请使用 [付费试点、PoC 与设计合作伙伴对比](/zh/blog/paid-pilot-vs-poc-vs-design-partner/) 。

另见 [MVP](/zh/glossary/mvp/) / [Discovery Phase 发现阶段](/zh/glossary/discovery-phase/) / [PMF](/zh/glossary/pmf/)

[阅读完整定义 →](/zh/glossary/proof-of-concept/)

024 / 073 engagement [#](#dedicated-team)

一支完整的外部团队，端到端地拥有一条工作流，配有自己的负责人，按你的路线图工作。供应商负责的是结果，而不仅仅是工时。

专属团队是一支被分配到你产品上的外部小队，配有自己的技术负责人，从规划到交付端到端地拥有一条工作流。与 [人员扩充](/zh/glossary/staff-augmentation/) 不同，你不必逐张工单地管理单个工程师。你设定方向和优先级；团队负责人处理日常执行、内部协调和交付。供应商负责的是结果，而不仅仅是达成结果所花的时间，这也是为什么它通常按月度产能费或 [Retainer](/zh/glossary/retainer/) 计价，而不是按小时计费。

当你有一个完整的问题要交出去而不是一个空缺要填补时，它就合适：一条产品线、一个平台、一条能以清晰接口对接你组织其余部分的工作流。当你没有内部管理带宽去指挥单个承包人时，它也合适，因为团队会自我管理。当工作与你现有团队的日常决策深度交织时，它就不合适；这种交织正是人员扩充存在的意义。

诚实的权衡在于接口。专属团队降低了你每位工程师的管理开销，但在两个为同一产品工作的群体之间引入了一道协调边界。每当优先级快速变动、或上下文需要不断跨越这道边界流动时，它都会让你付出代价。把专属团队做好的团队会投资于一个单一清晰的对接人、一份共享的完成定义，以及足够的重叠工时来保持这道边界足够薄。

要警惕的失败模式，是那种只有名义上「专属」、私下却被切片分摊到另外三个客户身上的专属团队。你付的是被预留的产能和一个被拥有的结果；如果同一批工程师在你的产品和另外两个之间来回切换上下文，那你既得不到那份所有权、也得不到那份专注，只得到一份加价的人员扩充。要问清楚具体是谁在这支团队里、他们是否全职投入你的工作流，以及如果其中一人退出，连续性会怎样。一支真正的专属团队有稳定的成员构成和一个扛着上下文的具名负责人；一支假的则是一拨轮换的角色，外加一个替你转发消息的项目经理。

Wavect 把团队保持得小而资深，因此拥有你工作流的那支团队是能做决策的操盘者，而不是前面摆着个项目经理的一层初级人员。关于我们如何组织交付，请看 [软件开发](/zh/services/software-development/) 页面。

另见 [Staff Augmentation](/zh/glossary/staff-augmentation/) / [Retainer 保留费](/zh/glossary/retainer/) / [Time & Material](/zh/glossary/time-and-material/)

[阅读完整定义 →](/zh/glossary/dedicated-team/)

025 / 073 engagement [#](#nearshoring)

亦称: Offshoring / Outsourcing

把开发迁往一个邻近国家、邻近时区的供应商。被宣传的节省是日费率；真实的成本是协调税。

近岸外包（nearshoring）意味着把开发外包给一个邻近国家的供应商，通常在相差几个时区之内。对 DACH 地区的公司来说，这通常意味着东欧，而不是南亚或东南亚。本土（onshore）是本国、按本国费率的供应商。离岸（offshore）是遥远的那一端：最低的日费率、最大的时区差、最长的沟通链条。近岸位于中间，被当作甜蜜点来兜售：比本土便宜，比离岸更好合作。

被宣传的数字是日费率，而在日费率上近岸确实胜出。没人会写进方案的数字是协调税：因为时区重叠比看上去更短而损失的工时、因为规格说明跨越语言与文化鸿沟时传递不良而导致的返工、你这一侧用于评审、纠正和反复解释的资深时间。一个更便宜、却需要双倍指导、产出还得你重做的工程师并不更便宜。一旦工作需要的是紧密协作而非定义良好、自成一体的任务，廉价费率的算账就崩了。

近岸可以是正确的选择。对于范围明确、规格清晰、需求稳定、对接你团队的接口很薄的工作，费率上的节省是真实的，协调税也很小，而这种合作通常会采用 [人员扩充](/zh/glossary/staff-augmentation/) 或 [专属团队](/zh/glossary/dedicated-team/) 的形态。但对于含糊、快速变化或深度协作的工作它就崩了，而这恰恰是大多数早期和产品驱动型公司实际在做的工作。在为日费率做优化之前，先诚实面对你手上的是哪一种。

Wavect 是一家 DACH 咨询公司：同一个时区、在要紧的对话里用同一种语言、资深的人只需指导一次而不是三次。当你拿我们和近岸费率比较时，比较的应是包含协调税在内的总成本，而不是发票上的那一行。关于我们如何工作，请看 [软件开发](/zh/services/software-development/) 。

另见 [Staff Augmentation](/zh/glossary/staff-augmentation/) / [Dedicated Team](/zh/glossary/dedicated-team/)

[阅读完整定义 →](/zh/glossary/nearshoring/)

026 / 073 engagement [#](#custom-software-development)

亦称: Custom Software Development / 定制开发 / 软件定制

为单一组织的特定需求设计和构建软件，代码与知识产权归买方所有，而不是租用为普通客户打造的现成产品。

定制软件开发指为单一组织的特定需求、流程和客户设计并构建软件，而不是许可一个现成的产品。买方拥有成果：代码、知识产权和路线图。标准软件，无论是本地安装还是作为 [SaaS](/zh/glossary/saas/) 租用，是相反的交易：更便宜、当天可用，但为普通客户塑形，且归供应商所有。

诚实的起点：大多数公司不应该构建定制软件。如果问题是薪资、CRM、会计，或任何成千上万家公司共有的事情，一个经过验证的产品会比你能委托开发的任何东西更便宜、更快、维护得更好。定制开发只在两种情况下值回价格：软件本身就是你出售的产品，或者某个工作流真的是你的竞争优势，把它塞进通用工具会磨掉这个优势。“我们很特别"不是证据。一份写下来的、标准方案做不到什么的清单才是。

在商业上，定制开发只有几种合同形态： [固定价格](/zh/glossary/fixed-price/) 的 Werkvertrag 适合范围清晰的项目， [Time & Material](/zh/glossary/time-and-material/) 适合不断演化的范围， [Retainer](/zh/glossary/retainer/) 适合持续的产品工作。大多数项目的起步应该比野心小，先做一个 [MVP](/zh/glossary/mvp/) ，在为整个系统投入资金之前验证核心假设。而且每个定制系统都是一项长期承诺：只要它存在，就得有人运行它、打补丁，并偿还它的 [技术债](/zh/glossary/technical-debt/) 。

**在软件项目中何时最关键。** 在第一个决策点，在任何与供应商的对话之前：自建还是购买。成本、时间线、所有权以及你雇谁，全都从这个决定衍生出来。

**创始人通常会搞错什么。** 为大路货问题做定制开发，却为真正让自己与众不同的那个工作流租用通用工具。或者拿开发报价与订阅的第一年费用比较，而不是比较双方五年的总成本。

**Wavect 如何处理。** 我们以构建定制软件为业，但当诚实的答案是购买现成产品时，我们仍会这样告诉许多潜在客户，因为一个本该是订阅的定制项目帮不了任何人。参见 [Wavect 的软件开发](/zh/services/software-development/) 了解我们如何构建，以及 [定制软件 vs 现成软件](/zh/software-development-guide/custom-software-vs-off-the-shelf/) 了解这笔决策账。

另见 [SaaS](/zh/glossary/saas/) / [MVP](/zh/glossary/mvp/) / [固定价格](/zh/glossary/fixed-price/) / [Time & Material](/zh/glossary/time-and-material/) / [Technical Debt](/zh/glossary/technical-debt/) / [软件开发公司](/zh/glossary/software-agency/)

[阅读完整定义 →](/zh/glossary/custom-software-development/)

027 / 073 engagement [#](#software-agency)

亦称: Software Agency / 软件公司 / Software House / 软件服务提供商 / 软件供应商 / 软件开发合作伙伴

你雇来设计、构建并交付软件的公司。Software agency、软件服务提供商、dev shop、软件外包公司指的都是同一类公司，真正的差别在合作模式。

软件开发公司（software agency）是你雇来设计、构建并交付软件的公司：一个把问题变成可运行、有人维护的代码的外部团队。“Software agency”、“dev shop”、“软件外包公司"指的都是同一类公司；标签的差别在营销，不在实质。Wavect 就是其中之一。

真正差别巨大的是标签之下的合作模式。同一个词既可以指按小时出租初级工程师的人力商店，也可以指把工程师插进你团队的 [Staff Augmentation](/zh/glossary/staff-augmentation/) 供应商、完整承接一条工作流的 [Dedicated Team](/zh/glossary/dedicated-team/) ，或是被 [固定价格](/zh/glossary/fixed-price/) 成果约束的产品伙伴。在比较各家公司之前，先决定你买的是哪一种，因为它们的价格和风险画像没有可比性。

与替代方案相比：自由职业者更便宜，但是单点故障；自建团队控制力最强，但招聘要花几个月，而且无论有没有活都要付薪水；软件开发公司用更高的日费率换来一个交付过、并且经得起某个人离开的团队。 [Nearshoring](/zh/glossary/nearshoring/) 压低日费率，同时加上一笔协调税。完整的权衡见 [自由职业者 vs 开发公司 vs 自建团队](/zh/software-development-guide/freelancer-vs-agency-vs-in-house/) 。

真正区分各家公司的问题比官网上的客户 logo 更重要：究竟是谁写代码（你见过的人，还是你从未见过的替补席）、工程师的普遍资历有多深、知识产权归谁，以及交接时会发生什么。

**在软件项目中何时最关键。** 在你决定不用自己的员工来构建的那一刻。选错公司的形态，不是选了一家差公司，只是选错了模式，是软件预算最常见的死法之一。

**创始人通常会搞错什么。** 在不可比的模式之间比较日费率，选中销售最出色的那家，然后发现来路演的人不是来写代码的人。

**Wavect 如何处理。** Wavect 是一家由两位创始人运营的软件开发公司：与你交谈的人就是做架构、写代码的人，资深是结构使然。参见 [软件开发](/zh/services/software-development/) 了解我们如何交付，以及 [如何选择软件开发公司](/zh/software-development-guide/how-to-choose-a-software-agency/) 了解我们站在你的位置会问的审查问题。

另见 [定制软件开发](/zh/glossary/custom-software-development/) / [IT 服务提供商](/zh/glossary/it-service-provider/) / [Staff Augmentation](/zh/glossary/staff-augmentation/) / [Dedicated Team](/zh/glossary/dedicated-team/) / [Nearshoring](/zh/glossary/nearshoring/) / [固定价格](/zh/glossary/fixed-price/) / [Retainer 保留费](/zh/glossary/retainer/)

[阅读完整定义 →](/zh/glossary/software-agency/)

028 / 073 engagement [#](#it-service-provider)

亦称: Managed Service Provider / MSP / Systemhaus / IT-Dienstleister / 托管 IT 服务商 / IT Service Provider

按 SLA 运维和支持你现有 IT 的公司：网络、设备、服务器、云、服务台。与软件开发公司不同，后者构建此前并不存在的软件。

IT 服务提供商是你付钱让它把你现有的 IT 维持运转的公司。网络、工位、服务器、云租户、备份、身份、补丁，以及一个你的员工可以打电话求助的服务台。在德语市场，同一类公司叫 IT-Dienstleister 或 Systemhaus；在国际上通常叫 managed service provider（MSP）。商业形态是带 SLA 的服务合同：响应时间、可用性目标，以及按工位或按设备计的月费。

**这和软件开发公司是两门不同的生意。** 混淆是可以理解的，因为两者都是"你付钱的外部 IT 人员"。区分它们的是交付物。IT 服务提供商按可用性衡量：已经存在的东西继续运转。 [软件开发公司](/zh/glossary/software-agency/) ，也被搜索为软件服务提供商或 Softwaredienstleister，按交付衡量：此前不存在的东西现在跑在生产环境里。一个负责让灯亮着，一个负责把房子建起来。

合同类型的差别也源于此。托管 IT 建立在持续服务合同上，是一种附带可用性承诺的努力义务。定制软件交付自然建立在 [Werkvertrag](/zh/glossary/sow/) 上，是一种结果义务。比较两者的日费率没有意义，因为你买的不是同一种承诺。

超过一定规模后，大多数公司两者都需要，来自两个不同的供应商。这是正常健康的状态，不是采购失误。把"定制软件开发"作为副线的 Systemhaus，通常用与其托管服务主业完全不同的方式配置这条线，这一点值得直接问清楚。

**在软件项目中何时重要。** 写需求说明的时候。如果你请 MSP 构建产品，你通常会得到一个来自运维文化的小团队，按小时计费，为稳定性而不是为找到 product-market fit 而优化。如果你请产品型开发公司运维你的服务台，最好的情况是得到一个礼貌的拒绝。

**买方常犯的错。** 把同一份招标发给两个类别，然后并排比较答复。这些提案不可比：一个报的是每工位可用性，另一个报的是一个范围。先决定你买的是哪种交付物，然后在该类别内做短名单。

**Wavect 怎么做。** 我们只在软件这一侧。我们构建定制软件并交付，我们不做 IT 运维：没有服务台，不做工位或网络管理，没有 7x24 驻场值班。当客户已经有 IT 服务提供商时，我们在旁边构建，并把运行中的系统干净地交接出去。在 [IKB](/zh/case-studies/ikb/) 项目中，我们的工作位于这家公用事业公司自己的建设之内，涉及基础设施、设备和编解码器，第一年后完整移交。如果你还在判断到底需要哪个类别， [软件构建模式](/zh/software-development-options/) 把五个选项并排列了出来。

另见 [软件开发公司](/zh/glossary/software-agency/) / [定制软件开发](/zh/glossary/custom-software-development/) / [Staff Augmentation](/zh/glossary/staff-augmentation/) / [Retainer 保留费](/zh/glossary/retainer/) / [SoW](/zh/glossary/sow/)

[阅读完整定义 →](/zh/glossary/it-service-provider/)

## 技术

技术 · 27

我们所构建的技术栈，剥离掉供应商公关后的真实样貌。

029 / 073 technologies [#](#web3)

建立在公开区块链上的软件，用户把资产与身份保存在自己的钱包里，而不是供应商的数据库里。

Web3 命名的是一族技术，而非单一事物。它们共同的属性是：用户状态（资产、身份，有时是数据）存在一条公开区块链上，而不是在中心化数据库里。用户用一把自己持有的私钥签署交易。供应商无法冻结或删除他的账户。

在实践中，这个词覆盖钱包、 [智能合约](/zh/glossary/smart-contract/) 、去中心化交易所、NFT、DAO、 [账户抽象](/zh/glossary/account-abstraction/) 、 [ZK 系统](/zh/glossary/zero-knowledge/) 、跨链桥，以及坐落在上面这一切之上的应用层。Wavect 在 EVM（Ethereum 及其兼容链）、Solana、Cosmos、Polkadot、Near、Ton 与 ICP 上构建。

做决定时，举个实际例子：一位创始人想要一个忠诚度积分应用，而一份 BP 告诉他要把它放「链上」。套用三个测试。这些积分需要在公司破产后仍然存在吗？彼此不信任的多方需要在没有中心运营者的情况下共享这个账本吗？它们需要与其他链上系统做无许可的可组合性吗？对一个单一公司的忠诚度方案，答案是不、不、不，所以正确的工具是一个数据库，把它放上区块链只会增加 Gas 成本、密钥管理的支持工单，以及一个监管头疼问题。把任一个答案翻成是（比如积分可在相互竞争的商户之间兑换），算盘就变了。

创始人低估的奥地利与欧盟细微之处：一个看起来像支付工具或证券的代币，会把 MiCA、招股说明书规则和税务处理拖进范围。「去中心化」并不豁免你，把代币分类搞错的法律成本会远超合约的工程成本。在你写智能合约之前就把这件事定下来，而不是之后。

诚实的版本：多数 Web3 项目并不需要区块链。真正需要的那些（必须在供应商破产后仍然存在的资产、没有中心运营者的多方信任、无许可的可组合性）是有价值的。其余多是 VC 资助的分心项。取舍是永久性是双刃剑：让 web3 可信的那种不可变性，也意味着一个已发布的 Bug 是永远的 Bug，而价值从第一分钟起就在场。我们会告诉你你属于哪一类。

另见 [智能合约](/zh/glossary/smart-contract/) / [EVM](/zh/glossary/evm/) / [Solana](/zh/glossary/solana/) / [Zero-Knowledge](/zh/glossary/zero-knowledge/) / [Account Abstraction](/zh/glossary/account-abstraction/)

[阅读完整定义 →](/zh/glossary/web3/)

030 / 073 technologies [#](#zero-knowledge)

亦称: ZK / ZK 证明 / ZK-SNARK / ZK-STARK

一种密码学技术，可以在不泄露背后数据的前提下，证明某个陈述为真。

零知识证明允许一方（证明者）让另一方（验证者）相信自己知道某条信息，而不揭示这条信息本身。经典例子：在不暴露出生日期的情况下，证明自己年满 18 岁。

在生产中，ZK 有两类常见形态。ZK-SNARK 体积更小、验证更快，但需要一次 Trusted Setup。ZK-STARK 更大也更慢，但不需要 Trusted Setup 且抗量子。多数链如今已经为常见证明（身份、余额、投票资格）提供了预制电路，所以你不必为了发布一个验证它们的 [智能合约](/zh/glossary/smart-contract/) 而在编制里养一个密码学家。

ZK 真正赚回成本的地方，举个实际例子：一家受监管的交易所必须向审计师证明每个用户都通过了 KYC，却不把一份包含姓名和护照号的数据库交给审计师。一个零知识证明让交易所证明「这组账户全部通过了 KYC 验证」，而底层身份保持私密。在欧盟，GDPR 让那份护照数据库成为一项你宁愿不持有的负债，所以这份隐私不是锦上添花，它就是要点本身。反例同样有教益：如果一次受信数据库查询就能让验证者满意，那 ZK 就是昂贵的表演。

诚实的工程取舍，以及创始人最常犯的错误：以为难的部分是密码学。数学是可靠的。风险住在电路里。一个细微出错的电路会产出一个完美通过验证、却证明了错误陈述的证明，而这个 Bug 在有人利用它之前都是隐形的。这就是为什么 ZK 工作属于 [账户抽象](/zh/glossary/account-abstraction/) 及其他审计不可协商的链上原语附近，而不是当作一个营销功能拴上去。商业理由比炒作窄：当你需要在链上（或对一个交易对手）证明某个属性而不泄露数据时，ZK 是真正有价值的。对多数消费级应用、以及多数顺嘴提它的 [web3](/zh/glossary/web3/) 项目来说，它是杀鸡用牛刀。

另见 [Web3](/zh/glossary/web3/) / [智能合约](/zh/glossary/smart-contract/) / [Account Abstraction](/zh/glossary/account-abstraction/)

[阅读完整定义 →](/zh/glossary/zero-knowledge/)

031 / 073 technologies [#](#homomorphic-encryption)

亦称: FHE / Fully Homomorphic Encryption / TFHE / CKKS / 同态加密 / 全同态加密

一种密码学技术，让服务器可以在从不解密的前提下对加密数据进行计算。

同态加密让别人可以在你的数据上运行计算，而数据全程保持加密。客户端加密输入，服务器蒙着眼计算，只有客户端能解密结果。服务器什么都学不到，连答案都学不到。全同态加密（FHE）是它的一般形态：任意计算、不限深度，但要付出代价。

代价就是整个故事。FHE 比同一计算的明文版本慢约 1,000 倍到 10,000 倍，这排除了交互式负载和任何前沿模型尺寸的东西。真正在生产环境交付的是那个窄模式：私有查询和小而明确的计算。Apple 的 Live Caller ID Lookup 在不透露电话号码的前提下把陌生来电与服务器数据库比对（BFV 方案），Microsoft Edge 在看不到密码的前提下把它与泄露库比对，Zama 的协议在以太坊上以每秒几十笔交易结算加密交易。没有人把后端跑在 FHE 下，包括口袋最深的那几家公司。

在实践中，「FHE」是一个方案家族，各有各的甜区：TFHE 适合加密逻辑和比较，CKKS 适合近似数和机器学习，BGV/BFV 适合精确整数查询。工具链已经开源，强工程团队用得起来，但库的选择取决于工作负载：TFHE-rs 是成熟的 TFHE 起点，Apple 的 Swift 库适合 BFV 查询，而 CKKS 值得在 Poulpy、Lattigo、SEAL、OpenFHE 和 FIDESlib 这类 GPU 原生选项间做基准测试。参数选择和性能工程仍是专家活。如果目标是证明一个事实而不是在隐藏数据上计算， [零知识证明](/zh/glossary/zero-knowledge/) 是更好的工具；如果硬件信任根可以接受，可信执行环境能以接近原生的速度干同样的活。我们的 [FHE 深潜](/zh/blog/fully-homomorphic-encryption-practical-2026/) 载有有出处的 2026 年数字， [决策框架](/zh/blog/zk-vs-fhe-vs-mpc-vs-tee/) 则讲了 FHE 什么时候胜过替代方案。

另见 [Zero-Knowledge](/zh/glossary/zero-knowledge/) / [LLM](/zh/glossary/llm/)

[阅读完整定义 →](/zh/glossary/homomorphic-encryption/)

032 / 073 technologies [#](#account-abstraction)

亦称: ERC-4337 / AA

一种让区块链账户像智能合约一样工作的模式：无 Gas 交易、社交恢复、批量调用、自定义鉴权规则。

在标准 [EVM](/zh/glossary/evm/) 链上，每个账户要么是外部拥有账户（一把私钥），要么是 [智能合约](/zh/glossary/smart-contract/) 。ERC-4337 引入了第三类：用户以一个智能合约账户的身份进行交易。因为账户本身就是合约，它可以承载逻辑。这些逻辑可以替用户付 Gas、通过 Guardian 从丢失的密钥中恢复、把多个调用打包进一笔交易，或强制执行像日支出上限这样的自定义鉴权规则。

遇到具体失败的 operation 时，免费的 [ERC-4337 UserOperation 调试器](/zh/tools/erc-4337-useroperation-debugger/) 可以拆分打包 gas 与 paymaster 字段、解释 AAxx 错误，并按版本在本地计算哈希，不会请求链或 bundler。

对用户体验的影响很大。有了 AA，最终用户可以用邮箱加 Passkey 注册，而不再需要助记词。Gas 可以由应用代付，或用应用的代币支付，而非必须用 ETH。钱包可以对可疑交易做速率限制。代价是更高的链上复杂度和每笔交易更高的 Gas 成本。

举个实际例子：一个消费级支付应用想要非加密原生的用户。没有 AA，注册意味着「记下这十二个单词，丢了你的钱就永远没了」，这会扼杀漏斗。有了 AA，用户用一个 Passkey 注册，应用代付头几笔交易、让他们从不见到 Gas 费，丢失的设备通过 Guardian 而非助记词来恢复。同样的模式让钱包能在链上强制执行一个日支出上限，而那是一个中心化应用永远无法可信地做出的那种保证。

创始人常犯的错误是把 AA 当作一个勾选框。它改变了安全模型：社交恢复为普通用户去掉了助记词的自伤陷阱，却引入了 Guardian 被攻破这一新的攻击类别，对宁愿自己持有密钥的高级用户而言反而严格更差。诚实的取舍是，AA 用更多需要审计的合约代码和每个操作更多的 Gas，换来主流用户体验。Wavect 已经把账户抽象钱包和 Snap（MetaMask 插件）推到生产环境。这项技术是真实的，并且越来越主流。实现并不简单。如果一家供应商把 AA 当作便宜的附加项报价，请问清楚他们用的是哪一套基础设施、合约代码经过了哪些安全审计。适用于 [zero-knowledge](/zh/glossary/zero-knowledge/) 电路的同一套审计纪律，在这里同样适用。

另见 [Web3](/zh/glossary/web3/) / [智能合约](/zh/glossary/smart-contract/) / [EVM](/zh/glossary/evm/) / [Zero-Knowledge](/zh/glossary/zero-knowledge/)

[阅读完整定义 →](/zh/glossary/account-abstraction/)

033 / 073 technologies [#](#ai-agents)

亦称: AI 智能体 / Agentic AI

一种使用 LLM 决定下一步、调用工具执行决定、并循环直到完成目标的软件形态。

AI Agent 是这套循环，不是模型本身。模型（Claude、GPT、Gemini、开放权重 LLM）是决策者。Agent 是运行时：它给模型一个目标，让它调用工具（一个数据库、一个 API、一个代码解释器、另一个 Agent），常常经由 [MCP](/zh/glossary/mcp/) ，观察结果，并把循环喂下去直到完成。

这个区分要紧，因为 Agent 式系统的失败方式与直接的 LLM 应用不同。聊天机器人答错了，用户翻篇。一个答错的 Agent 会发出一封邮件、做一笔交易，或删一份文件。生产级 Agent 需要授权 Gate、可观测性和熔断器，而多数原型都跳过了这些。

最常见的生产失败，举个实际例子：一个客服 Agent 被给了一个「解决工单」的目标和一组工具。一张畸形工单把它送进一个循环，它把同一个查询工具调了几十次，一下午就烧光了模型预算，却从未抵达一个解决方案。修法不是一个更聪明的 Prompt，而是工程：一个硬性步数上限、一个成本天花板，以及一个会停下循环并升级给人的熔断器。任何会写的动作（发一条消息、做一笔支付、删一条记录）都加一个 Human-in-the-Loop 的 Gate；只读的循环通常可以无人值守地跑。

诚实的取舍与该避免的创始人错误：Agent 增加了非确定性、延迟，以及比固定流水线大得多的爆炸半径，换来的是处理那些步骤无法预先枚举的任务。多数被吹成「Agentic」的工作流其实是被充分理解的，用一条确定性流水线、中间放一两次 LLM 调用、常常再由 [RAG](/zh/glossary/rag/) 提供接地，会服务得更好。Wavect 的立场：先问 AI 是不是这里合适的工具，再问 Agent 是不是合适的 AI 形态。如果你能把步骤写下来，就别让模型即兴去演它们。

另见 [MCP](/zh/glossary/mcp/) / [RAG](/zh/glossary/rag/)

[阅读完整定义 →](/zh/glossary/ai-agents/)

034 / 073 technologies [#](#mcp)

一种开放协议，让 AI 模型可以安全地连接外部工具与数据源，而无需为每个模型单独写定制集成。

Model Context Protocol（MCP）之于 [AI Agent](/zh/glossary/ai-agents/) ，相当于 HTTP 之于 Web：一份共享、开放的标准，规定模型如何与外界其余部分对话。它由 Anthropic 在 2024 年末推出，并在 2025 与 2026 年被广泛采用。

技术形态：一个 MCP 服务器通过一份定义好的 schema 暴露资源、工具与 Prompt。任何 MCP 兼容客户端（Claude Desktop、Claude Code、API、一个 IDE 插件）都能发现并调用这些工具，而不需要按厂商写胶水代码。集成做一次，每个 MCP 客户端都受益。

这种杠杆，举个实际例子：一家公司把它的内部 CRM、分析数仓和文档库封装成三个 MCP 服务器。这个季度团队在用 Claude；下个季度出于成本原因他们试用另一个模型。如果函数调用绑死在一个厂商上，那次切换意味着重写每一个集成。有了 MCP，他们把新客户端指向同样这三个服务器就行了。集成成本只付了一次，不是每个模型一次。把这些服务器与对文档库的 [RAG](/zh/glossary/rag/) 配对，你就能从内部数据得到有接地的答案，无需定制管道。

诚实的取舍与创始人的错误：只有当你预期会更换模型、或想要可移植性时，MCP 才是正确的选择；如果你永久绑定在一个供应商上，朴素的函数调用更简单也没问题。更大的风险是安全。MCP 是一个传输协议，不是一个权限模型。一个草率的 MCP 服务器，把一个有写能力的工具配上薄弱的鉴权暴露出来，就是一个等着发生的「Confused Deputy」，模型会被骗去调用它不该调用的东西。运行第三方配置之前，可以用 [MCP Install Risk Scanner](/zh/tools/mcp-install-risk-scanner/) 在本地检查完整命令、路径、密钥、版本固定、网络和容器 flags。我们经常构建 MCP 服务器并已经把它们部署到生产；我们也为每一个都写一份安全评估，因为标准还在变，而失败模式是你的内部系统，不是一个聊天机器人说了句蠢话。只有当一个工具在模型循环里确实有用、且安全模型允许模型去调用它时，我们才把它封装进 MCP，对任何破坏性的动作都加上 Human-in-the-Loop。

另见 [AI Agents](/zh/glossary/ai-agents/) / [RAG](/zh/glossary/rag/)

[阅读完整定义 →](/zh/glossary/mcp/)

035 / 073 technologies [#](#rag)

在运行时把相关上下文注入 LLM Prompt，这些上下文来自你自己的数据，让模型基于你的知识回答，而不是它训练数据里的知识。

RAG 是让 LLM 能回答它没被训练过的数据相关问题的架构。机制很直接：拿用户的问题，从你的语料里检索出最相关的片段（通过向量检索、关键词检索，或一种混合），把它们塞进 Prompt，让模型回答。它是大多数有用的 [AI Agent](/zh/glossary/ai-agents/) 底下的那层接地。

RAG 之所以存在：用你的私有数据训练一个模型既贵又慢，而且你的数据一变它就过时。RAG 通过把数据当作运行时上下文来回避这一点。代价是检索质量成了瓶颈：一个拿到坏上下文的模型会自信地产出错误答案。

经典失败，举个实际例子：一家公司在它的帮助文档之上构建了一个客服机器人，Demo 令人印象深刻，然后在生产中它自信地引用了错误的退款政策。本能反应是怪模型并试一个更大的。答案依旧错，因为问题在上游：文档在句子中间被切块，Embedding 分不清「退款」和「退货」，而且没有一个 Reranker 把正确的段落推到顶部。换上更好的切块、混合搜索和一个 Reranker，同一个模型突然就显得聪明了。这个教训可以推广：当 RAG 出错时，几乎每次都先怀疑检索，再怀疑生成。

诚实的取舍以及 RAG 崩溃的地方：它在「能从少数几个段落里回答的查找式问题」上表现出色，而在「答案需要跨许多文档综合、或需要调和语料里的矛盾」时退化。到那个点上，你要的是一个更小的精选语料、一条逐步推理的 Agent 式流水线，或微调，而不是一个更大的检索器。不性感的真相是：80% 的工作是把检索做好（切块、Embedding、Rerank、混合搜索），20% 才是模型。把你的数据源封装成 [MCP](/zh/glossary/mcp/) 服务器会让检索层可移植，但不会让它变好。把 RAG 当作一键式功能来卖的供应商，卖的是容易的那一部分。

另见 [AI Agents](/zh/glossary/ai-agents/) / [MCP](/zh/glossary/mcp/)

[阅读完整定义 →](/zh/glossary/rag/)

036 / 073 technologies [#](#smart-contract)

亦称: Smart Contract

运行在区块链上的代码，确定性执行，一经部署便不可更改（除非你设计成可升级）。

智能合约是被部署到一条区块链上的程序。一经部署，它的字节码不可变，它的状态对公众可读，它的执行由没人能凌驾的共识规则治理。这种永久性既是特性也是风险：生产里的 Bug 永远是 Bug，除非你内置了升级机制（而升级机制本身就是一个漏洞面）。

多数生产级智能合约系统不是单一合约，而是一组：一个 Proxy 实现可升级，一个 Implementation 合约承载逻辑，常常还有一个访问控制合约承载治理。这种模式对任何做过版本化 API 的人来说都不陌生；只是出错的代价更高。

为什么部署纪律不同于普通软件，举个实际例子：在一个 SaaS 后端发布一个 Bug，你打个补丁、一小时内重新部署。在一个持有用户资金的合约里发布一个重入 Bug，攻击者能在你反应过来之前把它掏空，因为没有回滚，而且价值从第一个区块起就在线。这就是为什么问题不是「我们要不要审计」，而是「我们如何安全地结构化升级」。常见答案是把 Proxy 模式放在一个时间锁和一个多签之后：即时升级权威是一个单点故障，没有升级路径让你被第一个 Bug 困死，而对用户透明的时间锁升级是大多数生产系统收敛到的中间地带。

诚实的取舍与创始人常犯的错误：创始人把合约当作一个功能、把审计当作一个可选的报价项。对任何持有非琐碎价值的合约，审计是你能买到的最便宜的保险，通常是 Build 预算里的 1 到 2 周，对着全部在险价值。Wavect 用 Solidity 写 [EVM](/zh/glossary/evm/) 链上的合约，用 Rust 写 [Solana](/zh/glossary/solana/) 、Near 和 ICP 上的合约，而语言是「你的 [web3](/zh/glossary/web3/) 用例要求哪条链」的下游产物，不是一种偏好。我们建议在主网之前对任何要紧的东西做第三方审计，我们也已经把审计过的合约部署到生产。跳过审计，正是团队以昂贵的方式学到这一课的方式。

另见 [Web3](/zh/glossary/web3/) / [EVM](/zh/glossary/evm/) / [Solana](/zh/glossary/solana/) / [Account Abstraction](/zh/glossary/account-abstraction/) / [Zero-Knowledge](/zh/glossary/zero-knowledge/)

[阅读完整定义 →](/zh/glossary/smart-contract/)

037 / 073 technologies [#](#evm)

在 Ethereum 及数十条复制了它字节码格式的链上执行智能合约的运行时。

EVM 是 Ethereum 发明、后来成为 [智能合约](/zh/glossary/smart-contract/) 链事实标准的执行层。一个编译成 EVM 字节码的合约，能在 Ethereum 主网、Polygon、Arbitrum、Optimism、Base、BNB Chain、Avalanche C-chain，以及一长串 L2 与侧链上运行。

实际意义是：用 Solidity（或 Vyper）写你的合约，在 Ethereum 测试网上测试，再部署到匹配你成本与延迟目标的那条 EVM 链。可移植性是真的。链之间的取舍体现在速度、终局性、去中心化程度，以及它们基于哪一种 L2 框架。

选链，举个实际例子：一个需要与现有借贷和 DEX 合约组合的 DeFi 协议属于 Ethereum 主网或一条主流 L2，那个生态住在那里，哪怕 Gas 更高。一个用户无法容忍美元级费用的高频消费级应用属于像 Arbitrum、Optimism 或 Base 这样的 L2（同样的安全模型，十分之一到百分之一的成本），或者干脆离开 EVM、转向 [Solana](/zh/glossary/solana/) 。这个决定是安全对成本的取舍，而不是这个季度哪条链营销嗓门最大。

诚实的取舍与反复绊倒团队的错误：EVM 兼容不等于 Ethereum 等价。Gas 定价、Precompile、Opcode 支持和共识行为上的细微差别，意味着一个在主网通过的合约可能在一条侧链上崩。可移植性是一个起点，不是一个保证；部署前永远逐链重测。像 [账户抽象](/zh/glossary/account-abstraction/) 这样的账户级用户体验功能，在各链上成熟度也不同，所以在你承诺它之前先确认支持。

更深的取舍是你为便宜的费用放弃了什么。从主网迁到一条更便宜的 EVM 链，几乎总是意味着继承一个不同的信任模型：一条像 Polygon PoS 这样的侧链跑的是它自己的验证者集，而不是借用 Ethereum 的安全；一个 Rollup 加了一个你现在要依赖的排序器，以及一段回到 L1 的提款延迟。这些都不会出现在供应商放进幻灯片里的那张 Gas 费对比里。在你为单笔交易成本做优化之前，先决定你的应用实际需要保证什么。对 [web3](/zh/glossary/web3/) 构建，我们在 Solidity 与 Vyper 之间默认选 Solidity，因为更广的工具链和审计师的熟悉度，除非有强理由逆流而上。

另见 [Web3](/zh/glossary/web3/) / [智能合约](/zh/glossary/smart-contract/) / [Solana](/zh/glossary/solana/) / [Account Abstraction](/zh/glossary/account-abstraction/)

[阅读完整定义 →](/zh/glossary/evm/)

038 / 073 technologies [#](#solana)

高吞吐、低手续费的区块链，运行时与 EVM 完全不同。编程模型不同，取舍也不同。

Solana 与 [EVM](/zh/glossary/evm/) 不兼容。 [智能合约](/zh/glossary/smart-contract/) （在 Solana 里叫「Program」）用 Rust 编写，部署为 BPF 字节码，由 Solana 运行时执行。这套架构为吞吐（每秒数千 TPS）和低费做了优化，代价是验证节点对硬件要求更高、以及一种不同的（有人说更中心化的）去中心化分布。

对于用户支付低于一美分手续费、确认达到亚秒级的消费级应用，Solana 很难被打败。对于与 EVM 生态深度组合的 DeFi，跨链过去的工程量并不小。哪条链合适，取决于哪种取舍对你的产品更重要。

绊倒 EVM 团队的那个坑，举个实际例子：Solana 的编程模型是基于账户的，而不是基于合约状态的。你要显式地把一笔交易触及的每个账户传进去、你要管理账户上的租金（rent）、你从一开始就要考虑并行执行。一支熟练于 Solidity 的团队会习惯性地低估这段爬坡、发布在顺路径下能跑的代码，然后撞上账户所有权和租金方面在 Ethereum 里没有对应物的边缘情况。为这个模型转换预留真实的时间；它不是一次语法翻译。

诚实的取舍，以及「挑那条又快又便宜的链」这个创始人错误：Solana 的验证节点硬件要求高于 Ethereum，所以验证者集更小，历史上也出现过网络宕机（最近少了些）。对消费级支付和高吞吐应用，那个取舍通常是没问题的，吞吐值这个价。对一个核心承诺是抗审查的系统，在假定 Solana 过关之前，仔细审视威胁模型。

生态成本是这个决定的另一半。住在 EVM 链上的那种深度、可组合的 DeFi 和工具链，在 Solana 上并非全都存在，而跨链桥接资产本身就是一项不平凡、对安全敏感的操作，不是一次免费的导入。如果你的产品需要插进现有的链上协议，那股拉向 EVM 的力是真实的，应当与 Solana 的原始性能去权衡。如果你的产品大体自成一体、且受吞吐约束（支付、消费级应用、游戏），性能取胜，更小的生态很少咬你。Wavect 在 [web3](/zh/glossary/web3/) 栈里 Solana 与 EVM 都做交付。我们没有链偏好；我们有用例偏好。

另见 [Web3](/zh/glossary/web3/) / [智能合约](/zh/glossary/smart-contract/) / [EVM](/zh/glossary/evm/)

[阅读完整定义 →](/zh/glossary/solana/)

039 / 073 technologies [#](#lorawan)

亦称: LoRa / IoT / Long Range WAN

低功耗、远距离无线协议，把电池供电的传感器接入互联网，常用于智慧城市与农业 IoT。

LoRaWAN 是让大规模 [IoT](/zh/services/internet-of-things/) 在经济上可行的网络层。设备用纽扣电池能跑数年，传输很小的载荷（几百字节），却能触达数公里外的网关。取舍是：低带宽、不频繁的更新，以及一个为把网关覆盖弄对而存在的不平凡的部署阶段。

如果无线连接正常，但应用 payload 不对，可以使用免费的 [LoRaWAN Payload Codec 测试器](/zh/tools/lorawan-payload-codec-tester/) ，用可重复的字节 fixture 运行 TTN、ChirpStack 和旧式 JavaScript formatter，全程无需上传设备数据。

我们交付过的应用包括智慧城市传感器网络（停车、环境、垃圾）、农业监测和工业遥测。模式在所有这些里都一样：边缘是廉价的「哑」传感器；网关把数据聚合到一个 Network Server；Network Server 把数据转发到你的应用后端。

预算实际花在哪里、以及创始人犯的错误，举个实际例子：他们给传感器定价，却忘了覆盖。一片农场或一个城区需要把网关摆放到每个传感器都能触达至少一个，弄错就意味着死区、重传，以及本该撑数年却几个月就耗尽的电池。在一次真实部署里，现场勘测和网关摆位往往是项目里更难的那一半，远在单台传感器成本被签字确认之后。墙、地形和金属筒仓都吃掉距离，而你只有在现场测量时才会发现。

创始人匆忙下决定的另一件事是谁拥有这张网。用 LoRaWAN，你通常跑自己的网关，这意味着没有每设备的蜂窝账单，但有一份真实的责任：你运营网关、Network Server 和覆盖。蜂窝方案（NB-IoT、LTE-M）把这个翻转过来，运营商拥有他们触达之处的覆盖，你为此付一份每设备的数据套餐。对一个你控制的、密集而固定的部署（一个园区、一片农场、一个城区），在设备生命周期内，自己拥有这张网通常在成本上取胜。对一个设备数量低、不可预测地散布在各地区的部署，付钱给运营商比去搭一张你几乎用不上的覆盖更便宜。

诚实的取舍：LoRaWAN 用带宽和延迟换距离和电池寿命，而这个交换是不可协商的，不是可调的。当你需要在一片大范围内部署许多传感器、要数年的电池寿命、且只是时不时发几个字节时，它是正确的工具。当你需要高带宽、低延迟，或跟着设备走的每设备连接时，它是错误的工具；对那些场景，5G NB-IoT 或 LTE-M 通常更合适。在把自己绑到无线电之前，先决定你的产品实际活在哪个轴上。

[阅读完整定义 →](/zh/glossary/lorawan/)

040 / 073 technologies [#](#llm)

一种经过训练以预测下一个 token 的统计模型，这使它在语言任务上出奇地出色，而在任何需要保证正确性的事情上都不可靠。

LLM 是一种在海量文本上训练、只做一件事的模型：根据之前的全部内容预测下一个 token（大致是下一个词片段）。把足够多的这种预测叠加起来，就得到了流畅的回答、摘要、翻译和代码。这就是全部的诀窍。它不是人类意义上的推理，而是非常出色的模式补全。

这一点很重要，因为它同时解释了魔力与局限。LLM 对你的业务没有记忆，没有超出其训练截止日期的知识，也没有内置的保证它给出的流畅回答是真实的。它会用与正确事实完全相同的自信说出一个错误事实。这种失败有个名字，叫 [幻觉](/zh/glossary/hallucination/) ，它不是一个可以打补丁修掉的故障，而是下一个 token 预测在缺乏接地时必然产生的结果。把它当作工具，而不是神谕。

正确的架构，举个实际例子：一家公司想要一个能回答自家合同问题的助手。朴素的做法是直接问原始模型，结果得到自信而错误的引用。能跑通的做法是把模型包裹起来：用 [RAG](/zh/glossary/rag/) 在查询时检索相关的合同条款，让答案来自公司自己的文档而不是模型训练时刻的知识，输出对照一个 schema 做校验，任何触发法律动作的请求都经由人工。模型没有变聪明；是它周围的工程变得认真了。

创始人最常犯的错误，是用一个更大的模型去修一个接地问题，或者在真正需要检索时去做 [微调](/zh/glossary/fine-tuning/) 。微调改变的是风格和格式；它不能可靠地注入事实，而且你的数据一变它就过时。诚实的取舍：当你需要确定性的、可审计的输出时，LLM 就是错误的工具，税务计算、监管逻辑，任何「通常正确」就构成隐患的场景；而它正适合起草、分类、抽取，以及在你自己的数据上做搜索。放进一个 [Agent 式](/zh/glossary/ai-agents/) 循环里，它就能行动，而不只是回答，这又把赌注抬高了一层。我们在 [人工智能](/zh/services/artificial-intelligence/) 下构建的正是这种有接地、经校验的系统。当作真理来源使用时，LLM 是一个充满自信的隐患。

另见 [AI Agents](/zh/glossary/ai-agents/) / [RAG](/zh/glossary/rag/) / [MCP](/zh/glossary/mcp/) / [Fine-Tuning](/zh/glossary/fine-tuning/) / [Hallucination](/zh/glossary/hallucination/)

[阅读完整定义 →](/zh/glossary/llm/)

041 / 073 technologies [#](#prompt-engineering)

编写你发送给 LLM 的指令和上下文，使它产出你真正想要的输出。这是真正的工程，而不是某种魔法咒语。

Prompt 工程是构建你发送给模型内容的实践：任务描述、示例、约束、输出格式和上下文。在你告诉它之前，模型完全不知道你想要什么，而你怎么告诉它会极大地改变结果。含糊的 Prompt 得到含糊的回答。带示例和明确输出模式的精确 Prompt 得到你真正能上线的东西。

炒作把它包装成一种神秘技能。现实更平凡也更有用：它是迭代工程。你写一个 Prompt，针对真实案例测试它，看它在哪里失败，收紧指令或补充示例，再次衡量。系统 Prompt（位于每条用户消息之上的常驻指令）是大部分持久行为所在之处，所以真正的工作流向那里。

这里是诚实的部分：Prompt 工程是真实的，但它不是职业护城河。这些技巧一周就能学会，而模型也在不断变得更善于理解草率的 Prompt。无法被商品化的，是知道该把模型指向哪个问题、把它接入一个真实系统，以及评估输出是否好到足以信任。这就是工程，也是我们在 [人工智能](/zh/services/artificial-intelligence/) 下所做的事。

便宜的部分与昂贵的部分如何分野，举个实际例子：一个团队让一个 Demo Prompt 在五个精挑细选的输入上跑得很漂亮，就宣布功能完成、直接上线。到了生产环境，同一个 Prompt 在没人测过的、杂乱的真实输入上垮掉，因为没有一层 [RAG](/zh/glossary/rag/) 给它喂正确的上下文，也没有一套评估装置来衡量它出错的频率。Prompt 从来就不是难的部分。知道模型的 [上下文窗口](/zh/glossary/context-window/) 预算、把检索接进去、并在真实案例上衡量输出质量，才是真正能上线一个可靠功能的工作。对任何把「Prompt 工程」当作独立产品来卖的人保持警惕：Prompt 是便宜的部分，昂贵的部分是它周围的一切，检索、评估、护栏，以及把一个巧妙的 Prompt 变成可靠功能的集成。

另见 [LLM](/zh/glossary/llm/) / [RAG](/zh/glossary/rag/) / [Context Window](/zh/glossary/context-window/)

[阅读完整定义 →](/zh/glossary/prompt-engineering/)

042 / 073 technologies [#](#fine-tuning)

在你自己的示例上继续训练模型以改变它的行为，这对于风格和格式是正确的工具，而对于注入最新事实则是错误的工具。

Fine-Tuning 拿一个预训练模型，在一组精选的你自己的示例上进一步训练它，调整模型权重，使它倾向于你所演示的行为。你用它来固化一致的语气、特定的输出格式、领域词汇，或基础模型处理得笨拙的某项任务。它改变的是模型如何回应，而不是它能访问哪些事实。

真正要紧的决策是 Fine-Tuning 与 RAG 之争，而人们常常把它弄反。RAG 通过从你的数据中检索，在运行时注入最新的、会变化的事实，所以答案只和你最后一次更新文档一样新。Fine-Tuning 教授持久的行为，但把知识冻结在训练时刻，所以当你的事实会变化时它就是错误的工具，它也不能可靠地阻止模型编造东西，因为 [幻觉](/zh/glossary/hallucination/) 是靠接地来减少的，而不是靠微调。经验法则：为形式而调，为事实而取。许多真实系统两者都用，一个经过微调、以你自家风格回答的模型，再由检索为实时数据提供依据。

成本现实没有过去那么吓人，但依然真实。你需要一个干净、带标注的数据集（通常是数百到数千个示例）、训练运行本身，以及每当基础模型改进或你的需求变化时重新微调的持续成本。最后这项成本是团队会忘记的那一项。Fine-Tune 不是一次性项目，而是一项维护承诺。

如果需要一条当前且低成本的实施路线，请阅读 [用 Unsloth 和免费 Colab 微调 Gemma 4 的实战指南](/zh/blog/fine-tune-gemma-4-free-unsloth-colab/) 。它涵盖浏览器试点、资源限制、评测、许可证、导出以及进入生产前的差距。

Fine-Tuning 彻底取胜的场景，举个实际例子：一家公司需要在数百万次调用中，让每一次模型回应都返回严格符合某个内部 schema 的 JSON，并带有一种特定的、简洁的自家风格。Prompting 大多数时候能做到，但偶尔一次格式错误的回应就会弄坏下游系统，而把整份风格指南和 schema 塞进每个 Prompt，又会在每次调用上烧掉 token。一次微调把格式和语气固化进模型权重，于是这些指令不必再在上下文里重复，在那个调用量级上，回应既更可靠、单次又更便宜。那就是甜蜜点：持久的行为、高调用量，以及一种 Prompting 始终无法稳定拿下的格式。

Fine-Tuning 什么时候彻底取胜？当 Prompting 加检索无法可靠地产出你所需的格式或行为，而你又有足够多高质量的示例去教它时。拿不准时，先把 Prompting 和 RAG 用尽，因为它们改起来更便宜。我们在 [人工智能](/zh/services/artificial-intelligence/) 下做出这个自建还是微调的判断。

另见 [LLM](/zh/glossary/llm/) / [RAG](/zh/glossary/rag/) / [Hallucination](/zh/glossary/hallucination/)

[阅读完整定义 →](/zh/glossary/fine-tuning/)

043 / 073 technologies [#](#vector-database)

亦称: Embeddings / Vector Search / Vector DB

一种把文本存储为数值向量的数据库，使你能够按含义而非精确关键词来搜索，它是大多数 RAG 系统所运行的检索引擎。

向量数据库存储 Embedding：文本（或图像、或音频）的数值表示，其中相似的含义被映射到空间中相近的点。你不是去匹配精确关键词，而是用同样的方式嵌入用户的查询，并向数据库索取最接近的向量。这就是相似性搜索，正是它让系统在文档实际写着「订阅终止流程」时仍能找到「我怎么取消我的套餐」。

在 RAG 流水线中，这是检索层。你的答案质量在很大程度上取决于它：好的 Embedding 和好的搜索会返回正确的文本块喂给模型，差的则喂进垃圾，而模型会自信地把这些垃圾总结出来。这就是为什么决定 RAG 项目成败的通常是检索，而不是模型。

这里是供应商会跳过的部分：你常常并不需要专用的向量数据库。如果你的语料库很小（数千而非数百万个文本块），在你本就运行的 Postgres 上加一个向量扩展（pgvector）更简单、更便宜，也少运维一个系统。如果你的搜索主要由关键词驱动，朴素的全文搜索甚至可能直接胜过向量搜索。只有当规模、延迟或高吞吐量下的混合搜索确实证明其合理时，才动用专用向量数据库，而不是因为它出现在架构图上。

把这件事过度工程化的例子：一个团队要给几千页文档做一个内部助手，结果在还没有一个用户之前，就上了一个托管向量数据库、一条独立的 Embedding 流水线和一个 Rerank 服务。他们现在要运维四个系统，去回答本来用现有 Postgres 上的 pgvector 就能搞定的问题，而其中每一个都是一件新的要监控、要保护、要花钱的东西。那个枯燥的版本一周就能上线，并且在语料库真正变大之前都扩展得很好。当数字逼着你上（数百万个向量、严苛的延迟预算、高吞吐量的混合搜索）时，再去动用专用数据库，而不是因为加上它能让架构图看起来更唬人。

我们在 [人工智能](/zh/services/artificial-intelligence/) 下有意选择足够枯燥的方案，因为每多一个系统，就多一件要在凌晨三点保持运转的事情。

另见 [RAG](/zh/glossary/rag/) / [LLM](/zh/glossary/llm/)

[阅读完整定义 →](/zh/glossary/vector-database/)

044 / 073 technologies [#](#hallucination)

当 LLM 产出流畅、自信却纯属虚假的输出时，这是模型工作方式的直接后果，无法被完全消除，只能被减少。

幻觉是指模型生成了听起来正确而实际错误的东西：一个编造的引用、一个虚构的 API、一个貌似可信却虚假的事实。它不是你能打补丁修掉的故障。LLM 预测的是可能的文本，而一个流畅、听起来自信的回答在统计上就是可能的，无论它碰巧是否为真。模型没有「我不知道」的内在感觉，所以它用某个符合模式的东西来填补空白。

因为它是结构性的，诚实的定位是降低风险，而非消除。最大的杠杆是接地：在运行时通过检索（ [RAG](/zh/glossary/rag/) ）把真实事实给模型，让它从真实的源文本作答，而不是从它训练时刻的猜测作答。要注意 [微调](/zh/glossary/fine-tuning/) 在这里是用错了杠杆，因为它塑造的是行为，而不是提供事实。约束输出格式，让即兴发挥的空间更小。让模型引用你能核查的来源。而且至关重要的是要评估，构建一个真实问题的测试集，衡量系统出错的频率，并把这个数字当作一项像其他指标一样要追踪的质量指标。

这就是 AI 与 QA 相遇之处，而大多数团队会跳过它。在没有评估框架的情况下上线一个 LLM 功能，等于上线未经测试的代码却把它叫做完成。你需要在你的用户替你发现之前，就知道你的错误率。我们把这一点视为在 [Software Quality Assurance](/zh/services/software-quality-assurance/) 下不可协商的事项。

为什么评估装置不可协商，举个实际例子：一个团队手动测了十几个问题、看上去都很好，就把一个法律文档助手上线了。到了生产环境，它自信地引用了一条上传合同里根本不存在的条款，一位用户据此采取了行动，于是出现了一项真实的隐患。本能能抓住这个问题的那套装置并不光鲜：几百个带已知正确答案的真实问题，在每次改动时都跑一遍，产出一个单一的数字，即系统答错的百分比。没有它，你就不知道自己的错误率，也就意味着由你的用户替你发现，一次一个错误答案地发现。有了它，你就能在上线之前判断，对照风险，这个错误率是否可以接受。

在受监管或高风险领域，信任这一面就是全部的游戏。一个推荐电影的聊天机器人里的幻觉只是耸耸肩的事。同样的幻觉出现在金融、法律或医疗输出中就是一项隐患。让护栏与出错代价相匹配，永远不要让一个流畅的回答取代一个经过核实的回答。

另见 [LLM](/zh/glossary/llm/) / [RAG](/zh/glossary/rag/) / [Fine-Tuning](/zh/glossary/fine-tuning/)

[阅读完整定义 →](/zh/glossary/hallucination/)

045 / 073 technologies [#](#context-window)

LLM 一次能够考虑的最大文本量，以 token 计量，也是你为什么不能简单地把整个知识库粘进每个 Prompt 的原因。

上下文窗口是模型对单次请求的工作记忆，以 token 计量（一个 token 大约是四分之三个单词）。所有内容都必须装进其中：你的系统 Prompt、对话历史、你粘进去的任何文档，以及模型生成的回答。一旦超出窗口，模型实际上就看不到溢出的部分。

即使窗口很大，「直接把所有东西放进 Prompt」也会因三个原因而失败。第一，成本：大多数提供商按 token 计费，所以把一份巨大的文档塞进每次调用会让账单成倍增长。第二，延迟：更多 token 意味着更慢的响应。第三，也是最不明显的，质量，模型对埋在很长上下文中间的信息关注得不那么可靠，所以更多并不总是更好。一个聚焦的 Prompt 往往胜过一个臃肿的。

这正是 RAG 存在的原因。你不是把整个语料库倒进窗口，而是只为每个问题检索出少数相关的文本块，并只发送这些。你获得了大型知识库的好处，却无需为在每次请求中处理全部内容而付费。上下文窗口是预算，检索和好的 [Prompt 工程](/zh/glossary/prompt-engineering/) 是你如何明智地花掉它。

那个让团队意外的「迷失在中间」效应，举个实际例子：一家公司把一份 40 页的政策文档粘进 Prompt，问了一个答案落在第 20 页的问题。即便整份文档在技术上都在窗口之内，模型仍然答错，因为对埋在长上下文中间的材料，注意力会衰减。同一个模型，只递给它检索抽出来的那两段相关文字，就答对了。更大的窗口没有修好这个问题；更精准的上下文修好了。当一个新模型带着抢眼的窗口尺寸发布时，这正是创始人会忽略的反直觉之处：更大的容量并不等于更高的可靠性。

实用的要点：把上下文窗口当作一项带价签的稀缺资源，而不是免费空间。更大的窗口降低了压力，却没有消除它，成本和延迟仍然随你放进去的内容而增长。我们在 [人工智能](/zh/services/artificial-intelligence/) 下有意围绕这个预算来设计。

另见 [LLM](/zh/glossary/llm/) / [RAG](/zh/glossary/rag/) / [Prompt Engineering](/zh/glossary/prompt-engineering/)

[阅读完整定义 →](/zh/glossary/context-window/)

046 / 073 technologies [#](#blockchain)

一个共享的、只可追加的账本，由一组计算机在没有中心运营方的情况下达成共识。任何人都无法悄悄修改历史记录。

区块链是一种具有两个不寻常属性的数据库。第一，它只可追加：你可以添加记录，但无法在不被所有参与者察觉的情况下重写已有记录。第二，没有单一一方控制它。一组节点运行相同的软件，并通过共识机制（工作量证明、权益证明或一种许可制变体）就下一个区块达成一致。其结果是一个多方可以在彼此不信任的情况下信任的账本。

区块链大致分为两类。公有区块链（以太坊、比特币、Solana）是开放的：任何人都可以读取它、运行节点或进行交易， [智能合约](/zh/glossary/smart-contract/) 系统和更广义的 [web3](/zh/glossary/web3/) 技术栈都住在这里。私有或许可制区块链限制谁可以参与，这通常意味着你用额外的步骤重建了一个更慢、更复杂的普通数据库。如果一家公司控制了所有节点，你得到的不是区块链的优势，而是一个你现在必须运维的分布式系统。

一锤定音的那个问题，举个实际例子：一家物流公司想要一条区块链「好让合作伙伴信任货运数据」。走一遍三项测试。这些记录需要在公司破产后存续吗？并不需要，运行这张网的就是这家公司。互不信任的各方需要在没有运营方的情况下共享状态吗？接近了，但实际上有一方明显是中枢，其他人都连到它。它们需要与其他链上系统做无需许可的可组合性吗？不需要。所以他们真正想要的，是一个权限设好、带审计日志和签名条目的共享数据库，它更便宜、更快，也是他们现有团队就能运维的东西。那套区块链说辞，解决的是一个签名加一个只读副本早已解决的信任问题。

诚实的立场：大多数被宣传为需要区块链的项目其实并不需要。区块链只有在以下情况下才值得其复杂性：你需要能在运营方破产后存续的资产、彼此不信任的各方之间的共享状态，或无需许可的可组合性。其余的一切都是数据库。当公有链确实是正确选择时，手续费和吞吐量通常会把构建推向一条 [Layer 2](/zh/glossary/layer-2/) ，而不是基础层。我们交付过真正的区块链系统，也劝退过比我们构建的更多的客户。我们的 [区块链工作](/zh/services/blockchain/) 从你是否真的需要它开始。

另见 [智能合约](/zh/glossary/smart-contract/) / [Web3](/zh/glossary/web3/) / [EVM](/zh/glossary/evm/) / [Layer 2](/zh/glossary/layer-2/)

[阅读完整定义 →](/zh/glossary/blockchain/)

047 / 073 technologies [#](#layer-2)

亦称: L2 / Rollup / Layer-2

一条建立在基础区块链之上的链，以低成本、快速地处理交易，然后将证明回传到基础层以获得安全性。

Layer 2 是一条从 Layer 1（通常是以太坊）借用安全性的 [区块链](/zh/glossary/blockchain/) ，而不是从头运行自己的共识。L2 在基础链之外执行交易，将它们打包，并把结果回传到 L1。大多数 L2 都是 [EVM](/zh/glossary/evm/) 兼容的，所以同样的 Solidity 合约和工具链可以直接沿用。用户以一小部分成本和高得多的吞吐量，获得以太坊的安全保证。L2 之所以存在，是因为基础层的区块空间稀缺且昂贵：当以太坊繁忙时，一次简单转账的成本可能超过被转账的金额本身。

主流设计是 Rollup，它有两种类型。Optimistic Rollup（Arbitrum、Optimism、Base）假定交易有效，并允许一个挑战窗口，在此期间任何人都可以对欺诈性批次提出争议。ZK Rollup 使用零知识证明，在每个批次落到 L1 之前以数学方式证明其有效，从而消除了挑战延迟，但代价是更繁重的证明基础设施。Optimistic 在今天更简单、构建成本更低；ZK 是技术发展的方向。

那个让用户意外、也烧到没做规划的创始人的细节：回到 L1 的提款。在一条 Optimistic Rollup 上，挑战窗口意味着把资金从 L2 转到以太坊主网可能要花上大约一周，除非你付钱给第三方「快速桥」来垫付流动性。一个几秒钟就完成存款、并指望几秒钟就能提款的消费者，是不会去读你关于欺诈证明窗口的文档的；他只会觉得你的应用坏了，或者在偷他的钱。如果你在一条 Optimistic L2 上构建，提款体验是一个你从第一天起就必须围绕它来设计的产品问题，而不是一个实现细节。

Wavect 已在一条 L2（Boba Network）上交付生产系统，包括其混合计算模型，该模型允许智能合约在执行过程中调用链下代码。这种模式在将真实世界数据或繁重计算引入合约方面非常强大，而要安全地运维它确实很难。如果供应商把 L2 部署宣传为免费的扩展性胜利，请追问到 L1 的提款如何运作、终局性延迟有多长、以及由谁运行排序器。我们的 [区块链工作](/zh/services/blockchain/) 涵盖 L2 选型与部署。

另见 [EVM](/zh/glossary/evm/) / [智能合约](/zh/glossary/smart-contract/) / [Account Abstraction](/zh/glossary/account-abstraction/) / [Blockchain](/zh/glossary/blockchain/)

[阅读完整定义 →](/zh/glossary/layer-2/)

048 / 073 technologies [#](#defi)

由公有区块链上的 Smart Contract 而非银行或券商运行的金融服务（交易、借出、借入）。

DeFi 用代码取代金融交易中的中介。去中心化交易所（DEX）不靠券商撮合交易，而是使用自动做市商：一个在资金池中持有两种资产、并按公式为兑换定价的 [Smart Contract](/zh/glossary/smart-contract/) 。借贷协议不靠银行决定谁能获得贷款，而是让任何人凭借锁入合约的抵押品借款，抵押品常常是一种 [稳定币](/zh/glossary/stablecoin/) ，利率由供需算法设定。没有人审批你；合约只是执行。

真正的创新在于可组合性。因为每个协议都是同一条链上的公共合约，它们可以像乐高一样拼接在一起。一个协议中的头寸可以作为另一个协议的抵押品，再被包装并在第三个协议中交易，全部在一笔交易中完成。这是传统金融体系凭其封闭的 API 和结算延迟所做不到的。这也是 DeFi 故障会连锁的原因：当一块积木崩塌，堆叠在其上的一切也随之崩塌。

风险真实而具体。Smart Contract 风险：一个漏洞会掏空资金池，且没有退款机制。预言机风险：协议依赖价格喂价，被操纵的预言机会让攻击者凭借虚假抵押品借款。

创始人最低估的风险是监管，而不是技术。在欧盟，一家在 DeFi 轨道上构建、或提供 DeFi 相邻服务的企业，可能落入 MiCA、反洗钱义务以及牌照要求之内，「去中心化」并不能让你豁免。监管机构越来越多地去看谁在实际控制一个协议并从中获利，而不是看营销话术。如果你的模型假定 DeFi 的无需许可特性意味着没有合规负担，那就在上线前把一次法律评审算进成本，因为把分类搞错，比合约工作本身昂贵得多。我们交付过触及 DeFi 轨道的支付基础设施（Scramble），我们的立场是：对于那一小部分需要无需许可、可组合金融的用例，DeFi 很强大；而对于所有把它当作收益赌场的人，它是一种负担。我们的 [区块链工作](/zh/services/blockchain/) 从你属于哪一种开始。

另见 [智能合约](/zh/glossary/smart-contract/) / [Web3](/zh/glossary/web3/) / [Stablecoin](/zh/glossary/stablecoin/) / [Blockchain](/zh/glossary/blockchain/)

[阅读完整定义 →](/zh/glossary/defi/)

049 / 073 technologies [#](#dao)

一个通过 Smart Contract 协调的群体，其共享资金和决策由链上投票治理，而不是由董事会和银行账户治理。

DAO 是一种运行集体的方式，其成员资格、投票和支出的规则都存在于 [Smart Contract](/zh/glossary/smart-contract/) 中。金库是一个链上钱包，只有当提案通过投票时才释放资金。投票权通常与代币持有量或成员资格挂钩。其卖点是协调变得透明且防篡改：任何人都可以审计金库，每一票都被记录，没有任何单一签署人能够悄悄掏空资金。它是少数几个价值不依赖代币价格的 [web3](/zh/glossary/web3/) 原语之一。

DAO 在一项特定工作上运作良好：管理一个共享的链上金库，其中成员彼此并不完全信任，需要可验证的规则来约定谁能花什么。投资俱乐部、协议参数治理和资助拨款都是真实的适用场景。我们为 FTW DAO 构建了链上治理与金库逻辑，在那里这种结构配得上它的复杂性，因为有真实的资金在各方之间汇集。

大多数 DAO 说辞含糊带过的，是法律地位，而在奥地利和更广的欧盟，这一点很要紧。DAO 不是一种受认可的法律形式。除非成员把它包进一个真正的实体（一家 GmbH、一个协会、一个基金会），否则法院可能把参与者当作一个负连带责任的合伙来对待，意味着某个成员可能要为这个集体的义务承担个人责任。「代码即组织」是一条不错的工程原则，却是一条危险的法律原则。任何触及真实资金或真实交易对手的 DAO，都需要在智能合约之下垫一个真正的法律外壳，这要在上线之前就定好，而不是在第一次纠纷之后。

DAO 在哪里沦为作秀：对实际上并不在链上的决策进行治理、把权力集中到少数巨鲸手中的代币加权投票，以及作为营销标签、而背后团队仍掌控管理员密钥的「社区治理」。如果艰难的决策仍在私人聊天中做出、投票只是橡皮图章，那你拥有的是一家穿着 DAO 戏服的普通公司。我们会告诉你你正在构建的是哪一种。请参阅我们的 [区块链工作](/zh/services/blockchain/) 。

另见 [Web3](/zh/glossary/web3/) / [智能合约](/zh/glossary/smart-contract/) / [Blockchain](/zh/glossary/blockchain/)

[阅读完整定义 →](/zh/glossary/dao/)

050 / 073 technologies [#](#nft)

区块链上一个独一无二、可转让的代币，指向某个特定事物：一项资产的所有权、一项访问权或一条记录。常常是一张 JPEG，有时确实有用。

NFT 是一种用于不可互换资产的代币标准（以太坊上常见的是 ERC-721）。一美元是可互换的：任何一美元都和另一美元一样好。一份特定房屋的产权证则不是。NFT 是那份产权证的链上等价物：一条绑定到某个所有者地址、可转让、且任何人都可验证的唯一记录。代币实际代表什么是一项设计决策，而价值问题的很大一部分取决于把这项决策做对。

诚实的区分在于实用价值与投机之间。真正的实用价值：现实世界资产（RWA）的代币化所有权、用于进入某项服务或活动的访问权、一份成员资格凭证，或玩家真正掌控的游戏内物品。在这些情况下，NFT 完成了数据库行无法完成的工作，因为所有者可以无需许可地转让或出售它，而且它能在发行方之外存续。我们为 LivLive 构建了由 NFT 支撑的机制，在那里代币用于进入现实世界的体验，而不是作为收藏品。

一个会悄悄弄垮幼稚 NFT 项目的细节：链上的那个代币通常只是一个指针，而它所指向的东西往往住在一台普通的 Web 服务器上。如果那台服务器宕机、或公司不再为它付费，那个「永久」的 NFT 现在就指向了空无，一个由区块链背书的坏图链接。认真对待所有权主张的项目，会把被引用的资产存到像 IPFS 这样的内容寻址存储上、或直接存到链上，这样代币所代表的东西能与代币活得一样久。如果一个供应商说不清那项真实资产存在哪里、由谁让它保持存活，那这份永久性就是营销。

投机的情形占据了市场的大部分：一个指向某张 JPEG 的代币，其唯一价值就是下一个买家愿意付更多钱。这在技术上没有任何错，但它是一个带区块链结算的收藏品市场，而不是一个生产力工具。如果供应商向你的业务推销 NFT，问题总是相同的：代币让持有者能做什么是数据库做不到的，以及这种所有权是否需要在你公司之外存续？我们的 [区块链工作](/zh/services/blockchain/) 从这里开始。

另见 [智能合约](/zh/glossary/smart-contract/) / [Web3](/zh/glossary/web3/) / [Blockchain](/zh/glossary/blockchain/)

[阅读完整定义 →](/zh/glossary/nft/)

051 / 073 technologies [#](#crypto-wallet)

亦称: Self-Custody Wallet / Web3 Wallet

持有你区块链资产密钥并对交易进行签名的软件。钱包真正存储的是密钥，而不是币本身。

加密钱包并不持有币；币存在于区块链上。钱包持有控制这些币的私钥，并用它对转移或花费资产的交易进行签名。这就是全部要害：谁持有密钥，谁就持有资产。丢失密钥，资金便无从找回；泄露密钥，攻击者会立即掏空账户。大多数钱包以十二个单词的助记词备份密钥，那是这个单点故障的人类可读形式。

第一个分叉是托管式与自托管式之分。托管式钱包（一个交易所账户）替你保管密钥，就像银行保管你的钱：方便、可由客服找回，而且只与那家公司一样安全、只与其偿付能力一样可用。自托管式钱包把密钥交到用户手中：没有人能冻结或没收资产，而当用户丢失助记词时也没有人能帮忙。这种在控制权与安全网之间的取舍，是整个领域决定性的用户体验难题。

有一条值得弄懂的监管界线，因为它会彻底改变你的义务：一个真正自托管的钱包，只有用户能动资金、你从不碰他们的密钥，这通常能让你避开那些约束交易所的资金传输与托管牌照体系。而一旦你的产品能够移动用户资金、保管密钥、或介入帮其找回，你就可能已经踏进了托管的地界，连同它所带来的全部牌照、KYC 和反洗钱负担。恢复功能恰恰是这件事变得微妙的地方：一个由你公司充当守护人之一的「社交恢复」方案，在监管者眼里，和一个只有用户自己选定的联系人持有密钥分片的方案，看起来非常不同。设计恢复模型时要把法律分类放在心上，而不只是用户体验。

[账户抽象](/zh/glossary/account-abstraction/) 是最可信的解决方案。通过让钱包本身成为一个 [Smart Contract](/zh/glossary/smart-contract/) ，你可以加入社交恢复（受信的守护人恢复访问权）、无 gas 交易、支出限额，以及用邮箱和通行密钥（passkey）而非助记词来注册。我们已在生产中交付自托管钱包，包括 Scramble 和 MetaMask Snaps，我们的看法是：仅靠助记词的钱包对主流 [web3](/zh/glossary/web3/) 用户而言是死胡同。在让非技术人员持有可观价值之前，必须先解决好恢复方案。请参阅我们的 [区块链工作](/zh/services/blockchain/) 。

另见 [Account Abstraction](/zh/glossary/account-abstraction/) / [智能合约](/zh/glossary/smart-contract/) / [Web3](/zh/glossary/web3/)

[阅读完整定义 →](/zh/glossary/crypto-wallet/)

052 / 073 technologies [#](#stablecoin)

一种旨在保持稳定价值的区块链代币，通常锚定一单位法定货币，让你能在链上交易而不受加密货币价格波动的影响。

稳定币是一种试图与稳定资产保持锚定的代币，几乎总是美元。其要点是保留区块链的结算速度和全球触达，而不带有那种使比特币或 ETH 无法作为记账单位的波动性。你可以像收发电子邮件那样持有、发送和接收稳定币：数秒内最终确认、跨境、无需银行居中。这就是真正的用例，尤其适用于流入和流出银行基础设施薄弱地区的支付与汇款。

锚定如何维持，决定了风险。法币支持的稳定币（USDC、USDT）在银行账户中持有真实的美元和国债，并按每美元铸造一枚代币。锚定的可靠程度只取决于储备和发行方的诚信，因此储备证明很重要。加密抵押的稳定币（DAI）以链上资产超额抵押，用托管风险换取市场崩盘时的清算风险，它们也是大多数 [DeFi](/zh/glossary/defi/) 借贷的支柱。算法稳定币试图凭供应机制、在没有真实支持的情况下维持锚定，而那片墓地（Terra/UST，数十亿蒸发）正是严肃从业者避开它们的原因。

欧盟的监管图景如今已是具体的，而非理论上的。在 MiCA 之下，稳定币（电子货币代币和资产参考代币）被明确纳入监管，带有储备、披露和发行方授权方面的要求，而且规则限制了非欧元稳定币在欧盟境内大规模用于日常支付的方式。对任何在奥地利或更广的欧盟、在稳定币轨道上构建支付流程的企业而言，问题不再是「这是否被允许」，而是「哪一种币、由谁发行、在哪一项授权之下」。这是一个要在你写集成之前就做的设计决策，因为给一个已上线的支付产品事后补合规，是那条昂贵的路。

我们在稳定币轨道上构建过支付基础设施（Scramble），也做过稳定币相邻的系统（Zybra），所以这个立场有据可依：稳定币是加密货币中用于转移价值的、最真正实用的 [web3](/zh/glossary/web3/) 原语，而锚定从来都不是免费的。请始终弄清楚是什么在支撑这枚币、谁能冻结它，以及在挤兑时会发生什么。我们的 [区块链工作](/zh/services/blockchain/) 把锚定模型当作头等的设计决策来对待。

另见 [DeFi](/zh/glossary/defi/) / [Web3](/zh/glossary/web3/) / [Blockchain](/zh/glossary/blockchain/)

[阅读完整定义 →](/zh/glossary/stablecoin/)

053 / 073 technologies [#](#microservices)

一种把应用拆分成许多个可独立部署的小服务的架构，它以真正的分布式系统复杂性为代价，换来扩展能力和团队独立性。

微服务意味着把一个应用拆分成许多个小服务，每个服务负责业务的一块，且每个都能独立部署。你得到的不是一个所有东西都在同一进程中运行的程序，而是一支通过网络彼此通话的服务舰队。这个承诺是真实的：团队可以独立交付，你可以只扩展需要扩展的部分，而且一个服务可以故障却不拖垮整个系统。

代价同样真实，而且通常被低估。一旦你的函数调用变成跨网络的 [API](/zh/glossary/api/) 调用，你就有了一个分布式系统，而分布式系统很难。你继承了网络故障、延迟、分散在许多数据库中且没有简单事务的数据、服务之间的版本控制，以及运行、监控和调试许多活动部件而非一个的运维负担，这又抬高了对你 [CI/CD](/zh/glossary/ci-cd/) 成熟度的要求。一个过去只是一段堆栈跟踪的 bug，现在变成横跨五个服务和三个队列的追踪。

诚实的立场：大多数初创公司应该从单体（monolith）开始。一个结构良好的单一应用构建更快、调试容易得多，而且完全有能力把你带到真正的营收。当你有一个具体理由时再拆分成 [微服务](/zh/services/software-development/) ，比如团队大到一个代码库成为瓶颈，或一个工作负载确实需要独立扩展，而不是因为微服务是流行的答案。过早的微服务，是小团队把一个难题变成十个难题的方式。

Polity 运行在七个微服务上，这对它的规模和团队结构而言是正确的决定。这正是要点：架构应当跟随问题和组织架构图，而不是一场会议演讲。把边界画在它们确实能降低耦合的地方，并接受你画的每一条边界都是一次你现在必须捍卫的网络调用。

另见 [SDLC](/zh/glossary/sdlc/) / [CI/CD](/zh/glossary/ci-cd/) / [API](/zh/glossary/api/)

[阅读完整定义 →](/zh/glossary/microservices/)

054 / 073 technologies [#](#api)

亦称: REST API / REST

一段软件与另一段软件对话所经由的约定契约，双方都无需知道对方内部是如何运作的。

API 是一段软件与另一段软件对话的既定方式。它说：这是你可以让我做的事，这是你确切的请求方式，这是你会得到的返回。其全部意义在于，调用方不需要知道工作在内部是如何完成的，只需要知道发送什么、期待什么。你手机上的天气应用并不知道天气服务是如何运作的。它只知道那个 API，发送一个请求，然后得到一份预报。

关键的想法是契约。双方就请求和响应的形态达成一致，只要这份契约成立，任何一方都可以自由更改自己的内部实现。同样这种契约纪律，正是让一套 [微服务](/zh/glossary/microservices/) 架构得以维系的东西，也是 [MCP](/zh/glossary/mcp/) 所标准化的那个想法，好让 AI 模型无需定制胶水代码就能调用工具。你会听到的两种常见风格是 REST 和 GraphQL。REST 把一切都建模为你通过标准 Web 请求读写的资源，是大多数 Web 和移动后端的默认选择；GraphQL 让调用方在一个请求中精确地索取它想要的字段。两者都只是定义同一份契约的规范化方式。

API 设计是你做出的最持久的决策之一。内部代码你可以在一个周末重构。一个公开 API，别人的软件依赖于它确切的形态，因此更改它会破坏他们的集成，这意味着你往往根本无法在不经历一次痛苦的版本化过程的情况下更改它。一个干净、命名良好、一致的 API 会优雅地老去。一个草率的则会变成你在每一次未来更改中都要缴纳的永久税。我们把 API 设计当作 [软件开发](/zh/services/software-development/) 的一等组成部分，而不是末尾才拼装上去的事后想法。

诚实的看法：大多数「集成简直是噩梦」的抱怨，都可以追溯到一个为了交付一个功能而仓促设计、随后被迫承载十个功能的 API。早早把时间花在契约上。这是你以后最难更改的部分。

另见 [Microservices](/zh/glossary/microservices/) / [MCP](/zh/glossary/mcp/)

[阅读完整定义 →](/zh/glossary/api/)

055 / 073 technologies [#](#saas)

你租用而非拥有的软件：供应商托管它、运行它并收取订阅费，而客户只需通过浏览器登录。

SaaS 是一种交付和商业模式，而不是一种技术。供应商不是把软件的一份副本卖给你让你自己安装和运行，而是托管它、运营它，并按周期性费用通过 Web 给你访问权限。你登录、你使用、你从不碰服务器。Salesforce、Slack 和 Notion 都是 SaaS。客户租用能力，而不是购买和维护软件。

其决定性的技术特征是多租户（multi-tenancy）：一个运行中的系统同时服务许多客户，他们的数据彼此隔离。这一个选择塑造了一切。你为租户之间的隔离和安全而设计，为一次性向所有人部署更新而不破坏任何人而设计，并为随客户增加而扩展而设计，而不是一年发布一次新版本。这种扩展是落在一个单体里、还是落在 [微服务](/zh/glossary/microservices/) 里，是另一个独立的决策，它应当跟随负载，而不是跟随潮流。它也改变了运维，因为现在是供应商承担正常运行时间、备份和安全这一持续的责任，而不是客户。

商业模式是另一半。收入是一种订阅，通常按月或按年，这意味着关系不在销售时结束，而是在那里开始。重要的指标变成了经常性收入、流失率（churn）以及服务每个客户的成本。定价通常与价值或用量挂钩：按席位、按层级或按用量。如果定价模式搞错了，一个技术上卓越的产品仍会在每个客户身上亏钱，所以定价既是销售决策，也同样是架构决策。

我们端到端地构建 SaaS 产品，从多租户 [架构](/zh/services/software-development/) 到客户登录进去的 [Web 应用](/zh/services/web-apps/) ，通常从一个 [MVP](/zh/glossary/mvp/) 起步，并在产品找到 [PMF](/zh/glossary/pmf/) 之后再加固它。Polity 就是一个 SaaS 产品。创始人低估的诚实之处：周期性模式意味着你正在签约承担对正常运行时间、安全和支持的永久责任，这是一项真实的运营成本，而不是一次性的构建。

另见 [MVP](/zh/glossary/mvp/) / [PMF](/zh/glossary/pmf/) / [Microservices](/zh/glossary/microservices/)

[阅读完整定义 →](/zh/glossary/saas/)

## 方法论

方法 · 18

软件真正是怎么交付出来的，超越框架 T 恤的层面。

056 / 073 methodology [#](#agile)

亦称: 敏捷

一族软件开发实践，重视短迭代、频繁的客户反馈，以及根据交付结果回头调整计划。

Agile 比多数人意识到的更老（宣言出自 2001 年），落地得也比多数团队愿意承认的更糟。最初的想法很简单：计划做得比你能预测的更远，就是浪费工作，所以短计划、发布、学习、再计划。其他一切（Scrum、Kanban、SAFe、 [Sprint](/zh/glossary/sprint/) 、Retro、Story Point）都是叠在上面的实施细节。

对一支声称「在做 Agile」的团队，最有用的问题是：上一次因为上周发布的东西而改变计划，是什么时候？如果答案是从来没有，那这支团队是在用两周一块的瀑布。

区别，举个实际例子：两支团队都跑两周 Sprint。A 队做演示，看到一个路线图上没人预测的功能才是用户真正点击的那个，于是把下个 Sprint 围绕它重排。B 队做演示，把反馈记进一份文档，然后按他们一月份写下的计划继续，因为计划就是计划。A 队是 Agile 的。B 队有 Agile 的仪式和一个瀑布的脑子。仪式是一样的；只有「是否愿意根据证据行动」不同，而那就是全部胜负所在。

诚实的取舍与创始人错误：Agile 不是跳过计划的许可证，它也不免费。它用长周期的可预测性换快速学习，而当范围、监管或一份接口契约真的不能变时（认证医疗器械、航电、某些硬件），这恰恰是错的。即便在那里，原始原则在团队内部依然适用；面向外部的流程只是看起来更像 [瀑布](/zh/glossary/sdlc/) 。Wavect 在原始意义上是 Agile 的：我们在短周期里工作、频繁演示、靠 [CI/CD](/zh/glossary/ci-cd/) 让发布变便宜，并且愿意把结果证明是错的工作扔掉。我们对认证产业版的 Agile 抱怀疑态度，那种把会议节奏本身当成目标、把 [TDD](/zh/glossary/tdd/) 套件写来给人看而不是为了信心的做法。

**在软件项目中何时最关键。** 当范围仍可能改变，因为市场还在不断教你东西时，多数早期产品都是如此。Agile 用长周期可预测性换快速学习，这种交换只有在你真的愿意根据所发布的东西去行动时才划算。

**创始人通常会搞错什么。** 他们买下仪式，却保留一颗瀑布脑：两周 Sprint、故事点、复盘，加上一份从一月起就没变过的计划。没有「依据证据改变方向」意愿的仪式，是伪装过的瀑布。

**Wavect 如何处理。** 我们是原始意义上的 Agile：短周期、频繁演示、靠 CI/CD 让发布变便宜，并且会扔掉被证明做错的工作。当范围真的不能动时，我们直说并据此规划； [固定价格对比 Time and Materials 指南](/zh/software-development-guide/fixed-price-vs-time-and-materials/) 讲到了这种合同选择。

另见 [Sprint](/zh/glossary/sprint/) / [TDD](/zh/glossary/tdd/) / [CI/CD](/zh/glossary/ci-cd/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/agile/)

057 / 073 methodology [#](#tdd)

先写测试。看它失败。写让它通过的最简代码。重构。重复。

TDD 是一种纪律，不是方法论。循环是：红（写一个会失败的测试）、绿（写让它通过的最简代码）、Refactor（在不破坏测试的前提下清理）。照字面做，它产出高测试覆盖率的代码，以及一种对抗过度工程的强制力。这种纪律只有在那些测试每次变更都跑时才会有回报，所以 TDD 和 [CI/CD](/zh/glossary/ci-cd/) 是兄弟，不是分开的两件事。

多数团队嘴上做 TDD、实际却不做的原因：当下先写测试感觉更慢。复利的回报（Refactor 安全、回归覆盖、朝更小单元的设计压力）要数月之后才显现。到那时，团队早已停止先写测试，并说服自己它从没起过作用。

TDD 在哪里赚回成本、在哪里只是表演，举个实际例子：一个支付对账模块有棘手的边缘情况（部分退款、货币舍入、重试）。先写那个会失败的测试，迫使你在代码存在之前就陈述期望行为，而当六个月后有人「简化」舍入时，那套套件抓住了回归。那是 TDD 在为自己买单。再对照一个你两周后就要删掉的一次性数据导入脚本：在那里先写测试纯属开销。诚实的规则是对逻辑密集、出错代价高的代码做 TDD，其余的不做。

最常见的错误是把覆盖率当成一个目标。追 90%，团队就会为 Getter 和 Setter 写测试去凑那个数字，却跳过真正 Bug 所在的集成测试。覆盖率是一个有用的诊断、一个糟糕的目标；它是个会被刷分的指标。Wavect 在它有回报的地方用 TDD：任何和钱相关的东西做集成测试，任何面向客户的东西做契约测试，产品需要读得懂的地方做 [BDD](/zh/glossary/bdd/) 式验收测试，不平凡的逻辑做单元测试。我们把难的部分测好，而不是把所有部分平均地测，并且把它当作一个健康的 [Agile](/zh/glossary/agile/) 循环里的一项实践，而不是一个要打的勾。

另见 [BDD](/zh/glossary/bdd/) / [Agile](/zh/glossary/agile/) / [CI/CD](/zh/glossary/ci-cd/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/tdd/)

058 / 073 methodology [#](#bdd)

用业务方能读懂的语言写测试。然后让这些测试通过。

BDD 是把 [TDD](/zh/glossary/tdd/) 的测试语言改写成非工程师也能读懂的形式。Cucumber 之类工具用 Given/When/Then 格式，让一位产品经理也能签字。意图是让测试与它所验证的业务行为对齐，而不是与今天碰巧存在的实现对齐。

它在哪里真正有回报，举个实际例子：一个保险产品有一条规则，少于 30 天、且有有效保单的理赔自动通过。写成一个 Gherkin 场景（「Given 一份生效 30 天的保单，When 在保障窗口内提交理赔，Then 它自动通过」），产品负责人和合规审核人都能读它、确认它匹配真实规则，并在它发布之前抓住那个差一错误。那种共享语言的核对，正是 BDD 的全部价值，而它住在验收和集成层，那里正是「产品想要的」和「工程造出来的」之间的鸿沟、Bug 诞生的地方。

还有一项团队很晚才发现的维护成本。Gherkin 场景坐落在一层「Step 定义」之上，那是把每一行通俗英语映射到实际测试动作的胶水代码。那层胶水是真实的软件，必须随产品变化保持同步，而一个 Step 定义草率的大型 BDD 套件会变成它自己的维护负担，跑得慢、改起来脆。它的好处（一位利益相关者能读并签字确认行为）只有在确实有利益相关者去读时才抵得上那份开销。如果 Gherkin 由工程师写、由工程师读、从没被别人看过，你就是在为一个没有观众的翻译层付费。

诚实的取舍与常见错误：BDD 不是 TDD 的替代品，它是叠在上面的一层，而把它到处用就是那个错误。为一个琐碎函数写「Given 两个数，When 我把它们相加，Then 我得到和」是没有任何业务利益相关者会读的仪式。把 Gherkin 留给那些非工程师确实需要签字的测试，那条线以下用朴素的单元测试。像所有这些实践一样，BDD 是一段清醒的 [SDLC](/zh/glossary/sdlc/) 里的一个阶段，是为一个真实的沟通问题准备的工具，而不是一个为自身而采纳的流程。

另见 [TDD](/zh/glossary/tdd/) / [Agile](/zh/glossary/agile/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/bdd/)

059 / 073 methodology [#](#mvp)

能让你判断「这个想法是不是错的」的最小版本。不是「能发布的最小版本」，而是「能教会你东西的最小版本」。

MVP 里 Viable 这个词承担了几乎全部的重量，而几乎所有人都把它理解错了。Viable 不意味着「最终产品的精简版」。Viable 意味着「足以测试这个产品值得构建这一假设」。一个带 Waitlist 的落地页可以是一个 MVP。一个带三个功能的可运行产品可能是比那个落地页更糟的 MVP。

举个实际例子：一位创始人确信他的假设是「用户会为自动化的发票对账付费」。本能是花三个月去构建对账引擎。测试真正这一假设的更便宜的 MVP 是一个手动的：一个落地页、一个价格，以及一个人在幕后用手做对账（一个 Wizard-of-Oz MVP）。如果没人为手动版本付费，那个引擎本会是浪费掉的三个月。构建只在付费意愿被证明之后才开始，而这正是一段 [发现阶段](/zh/glossary/discovery-phase/) 所做的那种去风险。

有一个值得知道的奥地利资助褶皱。aws Preseed 及类似拨款常常围绕达到一个「原型」或「MVP」里程碑来框定，创始人有时让拨款的定义来支配构建，把 MVP 塞满那些勾选资助框、而不是测试假设的功能。用这笔钱学得更快，而不是去造一个比学习所需更重的 MVP。拨款奖励一个里程碑；市场奖励一个被验证的假设，而这两者并不总是同一个产物。

最常见的失败是去构建你六个月前想象的那个 MVP，而不是去测试本周最不确定假设的那个 MVP。每一周最有风险的假设都在变，而多数 MVP 在发布前就已过时。诚实的取舍：一个 MVP 有意地造得不足，所以它在你脑中那个打磨光滑的东西旁边会显得不起眼，而那份不适正是快速学习的代价。如果构建阶段跑过 8 到 12 周，你造的就不是一个 MVP，而是一个用更友善名字包装的 V1。Wavect 跑朝向 MVP 的短 [Agile](/zh/glossary/agile/) 周期，并在给构建定范围之前先命名假设。相关： [Fractional CTO 奥地利](/zh/services/fractional-cto/) 端到端覆盖 MVP 领导。

**在软件项目中何时最关键。** 在最开始，当你能买到的最有价值的东西，是在押上构建预算之前、便宜地弄清这个想法是不是错的。

**创始人通常会搞错什么。** 他们把「最小」读成「成品的小版本」，于是去造六个月前想象的那个 MVP，而不是测试本周最有风险假设的那个。如果构建跑过 8 到 12 周，那就是换了个友善名字的 V1。

**Wavect 如何处理。** 我们在给任何东西定范围之前先命名假设，然后造出能测试它的最小工件。见 [什么是发现阶段](/zh/software-development-guide/what-is-a-discovery-phase/) 来给想法去风险，以及 [如何为 MVP 选择技术栈](/zh/software-development-guide/how-to-choose-a-tech-stack-for-mvp/) 来让它保持低成本可改。

另见 [PMF](/zh/glossary/pmf/) / [Discovery Phase 发现阶段](/zh/glossary/discovery-phase/) / [Agile](/zh/glossary/agile/) / [Sprint](/zh/glossary/sprint/)

[阅读完整定义 →](/zh/glossary/mvp/)

060 / 073 methodology [#](#pmf)

市场以你来不及构建的速度把产品从你手里「拉」出去的那个点。在你感受到这股拉力之前，你还没有 PMF。

PMF 出了名地难定义又出了名地好识别。Marc Andreessen 的启发式仍然成立：当产品被用户、媒体与股权表同时拉动，而你的问题不再是怎么找到客户、而是怎么跟上他们时，你就知道你有了它。

PMF 之前，你做的几乎所有事都是一个赌。正确的组织架构图、正确的技术栈、正确的招聘计划，全都取决于哪一段客户真的在拉。PMF 之后，问题变成运营的：扩团队、加固技术栈、控制烧钱。

最昂贵的 PMF 之前错误，举个实际例子：一支团队融了一轮种子，招了四名工程师，花九个月构建一个由 Kubernetes 支撑、多区域、微服务的平台「好让我们能扩展」。他们扩展到了四十个用户、烧完了 Runway，而那个为数百万构建的架构从没被数百个用户测试过。相反的失败更少见但真实：一支团队找到了拉力、被报道了，而那台过载的单一服务器在整个市场都在看的那一周里崩了。这个工程决定完全是「你在 PMF 线哪一侧」的函数，所以诚实地命名这条线，比任何技术栈决定都更重要。

创始人回避的诚实取舍：承认你在 PMF 之前感觉像承认失败，于是 BP 把一场一次一个客户的苦战描述成「早期牵引」。如果获取仍是一场苦磨、且流失高到口碑无法承载增长，那么不管 BP 怎么说，你都在 PMF 之前，而正确的动作是继续发布那个能解决下一个不确定性的最便宜 [MVP](/zh/glossary/mvp/) ，而不是为一个你还没挣得的规模去构建。一段 [发现阶段](/zh/glossary/discovery-phase/) 帮你命名最有风险的假设；一位 fractional 运营者能在搜索期间防止昂贵的技术错误，但无法替代真正产生拉力的那种创始人对客户的执着。过了 PMF，你通常需要的是一位 CTO，而不是一位 [联合创始人](/zh/glossary/fractional-cofounder/) 。参见 [Fractional CTO 奥地利](/zh/services/fractional-cto/) 。

另见 [MVP](/zh/glossary/mvp/) / [Discovery Phase 发现阶段](/zh/glossary/discovery-phase/) / [Fractional Co-Founder](/zh/glossary/fractional-cofounder/)

[阅读完整定义 →](/zh/glossary/pmf/)

061 / 073 methodology [#](#sdlc)

一个软件项目从端到端要走的阶段：发现、设计、构建、测试、部署、运维、退役。

软件开发生命周期是把软件从想法到退役所经历的各个阶段归在一起的统称。不同方法论（ [Agile](/zh/glossary/agile/) 、瀑布、DevOps、持续交付）定义不同的阶段边界、以及在它们之间移动的不同方式。阶段本身大致不变：发现、设计、构建、测试、部署、运维、退役。

当作词汇用很有用，当作流程用就不一定。试图强推一套严格 SDLC 的团队，最后会堆出活不过第二个 Sprint 的文档开销。完全无视 SDLC 的团队，则会以痛苦的方式重新发现每个阶段（「我们没有部署计划就上线了」「我们从没想过怎么把这个系统下线」）。

人人都跳过的那个阶段，举个实际例子：一家初创公司两年里构建了三个内部服务、发布了、然后继续往前。没人负责「运维」，也没人规划「退役」。十八个月后，三个里有两个还在运行，没人记得为什么，唯一懂它们的那位工程师走了，而停掉任何一个可能会弄坏什么、也可能不会。那就是跳过生命周期后半段不开账单的成本。这件事前期做很便宜（指定一个负责人、写一份部署和拆除计划），事后发现则很贵。

你选的方法论主要决定阶段之间的边界有多刚。一套瀑布 SDLC 把它们严格按顺序跑、在每个门口签字确认；一套 Agile SDLC 把设计、构建、测试连续地交织，并随学习重访更早的阶段。无论哪种，阶段是同一组，这就是那个有用的洞见：争论「Agile 对瀑布」其实是在争论边界应该有多可渗透，而正确答案取决于你的需求还能变多少。

诚实的取舍与常见错误：创始人听到「SDLC」，要么把它过度形式化成一套门控、签字繁重、扼杀速度的流程，要么把它当作企业表演而跳过那些不光鲜的阶段。正确的姿态是把它当作一份「必须在某处发生的事」的清单，而不是一条要正步走过的序列。Wavect 偏好的形态：前面放一段付费的 [发现阶段](/zh/glossary/discovery-phase/) ，设计与构建在短周期里交织，从第一天起就有自动化的 [TDD](/zh/glossary/tdd/) 和 [CI/CD](/zh/glossary/ci-cd/) ，运维有清晰归属，退役有书面化的迁移路径。

**在软件项目中何时最关键。** 作为一份「必须在某处发生的阶段」清单：Discovery、设计、构建、测试、部署、运维、退役。跳过不光鲜的后半段，账单会以「没人愿意碰的无主服务」的形式在日后到来。

**创始人通常会搞错什么。** 他们摆向两个极端之一：把 SDLC 过度形式化成一套门控、签字繁重、扼杀速度的流程，或者把它当作企业表演而跳过那些阶段，然后在上线后以痛苦的方式重新发现每一个阶段。

**Wavect 如何处理。** 前面放付费 Discovery，设计与构建在短周期里交织，自动化测试与 CI/CD 从第一天起，运维归属清晰，退役有书面化。 [上线前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 和 [什么是发现阶段](/zh/software-development-guide/what-is-a-discovery-phase/) 覆盖了创始人最常跳过的那些阶段。

另见 [Agile](/zh/glossary/agile/) / [CI/CD](/zh/glossary/ci-cd/) / [Discovery Phase 发现阶段](/zh/glossary/discovery-phase/) / [TDD](/zh/glossary/tdd/)

[阅读完整定义 →](/zh/glossary/sdlc/)

062 / 073 methodology [#](#ci-cd)

每一次代码变更都自动构建、测试、准备发布。一些团队再进一步，每一次通过的构建都自动上生产。

Continuous Integration 意味着团队的代码在每次变更时都合并并构建，而不是在最后做一次大爆炸式集成。 [Continuous Delivery](/zh/glossary/continuous-delivery/) 意味着每一次成功的构建都距离生产只差按一次按钮。Continuous Deployment 把按钮也去掉：每个通过测试的构建自动发布。这三者是一架成熟度阶梯，不是同义词。

多数团队 CI 做得好，CD 时好时坏，Continuous Deployment 几乎从不做。瓶颈很少在工具上。它在于对测试套件的信任，以及团队在一小时内修好一个坏构建的意愿。没有这两样，自动化部署只是让 Bug 跑得更快。

藏在流水线速度里的杠杆，举个实际例子：一支团队有一条要跑 25 分钟的 CI 流水线。工程师不再在本地跑它，把变更攒成批、靠希望去合并，以躲开那段等待。Bug 在合并之间累积，团队当初采用 CI 想躲开的那种集成之痛悄悄回来了。把那条流水线为内循环砍到 10 分钟以内，工程师就会不停地跑它、在上下文还新鲜时抓住问题，整个 [Agile](/zh/glossary/agile/) 循环随之收紧。流水线速度不是锦上添花；它是每个工程师每一天的力量倍增器。

诚实的取舍与常见错误：创始人要「完整的 CI/CD」，好像它是一个开关，而其实 CI 主要是工具、CD 主要是纪律。CI 你一个下午就能有。真正的 Continuous Delivery 需要一套团队信得过、敢在后面发布的测试套件（靠一种 [TDD](/zh/glossary/tdd/) 习惯）、一条以分钟计的回滚路径，以及一个在部署点着什么时能响应的待命人。Wavect 每个项目从第一天起就配好 CI，作为一段清醒 [SDLC](/zh/glossary/sdlc/) 的一部分；是否配置 CD 取决于这个项目是否有让它安全的覆盖率和运维纪律。我们会告诉你你拥有的是哪一种。

**在软件项目中何时最关键。** 上线前以及之后的每一次改动。一条健康的流水线让团队能安全发布、在上下文还新鲜时抓住回归，而不是把改动攒成一批、靠运气合并。

**创始人通常会搞错什么。** 他们要「完整的 CI/CD」，好像它是一个开关。CI 主要是工具，一个下午就能有；真正的 Continuous Delivery 主要是纪律，一套团队信得过的测试、以分钟计的回滚，以及一个待命的人。没有这些，自动部署只是更快地发布缺陷。

**Wavect 如何处理。** 我们从第一天起配好 CI，只有当覆盖率和运维纪律让自动交付安全时才开启它。 [上线前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 精确列出了在真实用户到来之前，一条流水线必须做到什么。

另见 [TDD](/zh/glossary/tdd/) / [Continuous Delivery](/zh/glossary/continuous-delivery/) / [Agile](/zh/glossary/agile/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/ci-cd/)

063 / 073 methodology [#](#continuous-delivery)

亦称: CD / 持续交付

每一次变更都被自动准备成可发布形态。最后是否真的发布到生产，仍由人来按下那个按钮。

Continuous Delivery 是 Continuous Deployment 的负责任表亲。每一次变更都走过同一条自动化的构建、测试与发布准备流水线（即 [CI/CD](/zh/glossary/ci-cd/) 骨干）。出来的产物是可发布的。它是否真的发布，是一个人的判断。

多数团队停在 CD 而不进到完整 Continuous Deployment 的原因：一次糟糕发布的代价高到让环节里的一个人值这点延迟。当你的监控、测试覆盖与回滚故事都好到那个人已不再贡献信号时，再进到 Continuous Deployment。

按服务而非按公司来选，举个实际例子：同一家公司跑着一个营销站点和一个支付账本。营销站点非常适合完整的 Continuous Deployment，那里一次糟糕发布意味着一个拼写错误、回滚也很琐碎，所以每个通过的构建都能无人值守地发布。支付账本留在 Continuous Delivery、由一个人按按钮，因为那里一次糟糕发布会错误地移动钱，那个人是真正在贡献信号，而不只是延迟。把「我们要不要自动化部署」当作一个全公司统一的决定，正是那个错误；它是一个按服务的风险判断。

有一个值得点名的监管维度。在有变更控制或审计要求的领域（金融、医疗、任何在 GDPR 下触及个人数据的东西），Continuous Delivery 里那一步人工批准不只是风险管理，它往往就是审计师期望看到的那项书面控制：谁批准了这次发布、对着什么证据、在何时。这些场景里的团队不应当把完整 Continuous Deployment 当作一枚成熟度勋章去追；那道手动闸门是他们合规故事所依赖的一项特性。把直到按钮之前的一切自动化，然后把按钮留在审计链需要它的地方。

诚实的取舍：Continuous Delivery 给你近乎完整自动化的大部分速度，同时在那个不可逆的步骤上保留人的否决权，代价是当那个人慢了或不在时，否决权会成为瓶颈。毕业到它之上的前提是真实的、不是空想的：一套 [TDD](/zh/glossary/tdd/) 支撑、团队敢在后面发布的套件、一次以分钟而非小时计的回滚，以及一个待命轮值。没有这三样，「Continuous Delivery」就是一个没人敢按的按钮，而那条流水线只是叠在一段本来健康的 [SDLC](/zh/glossary/sdlc/) 之上的装饰。

另见 [CI/CD](/zh/glossary/ci-cd/) / [TDD](/zh/glossary/tdd/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/continuous-delivery/)

064 / 073 methodology [#](#vibe-coding)

亦称: Vibe Coded / Vibe-Coded

通过给 AI 工具下提示词来构建软件（Lovable、Cursor、Claude Code、Replit、Bolt、v0），并不加阅读地接受它生成的东西。做出演示很快，上生产很危险，因为模型优化的是能跑起来的代码，不是能扛住真实用户的代码。

Vibe coding，就是向 AI 编程工具描述你想要什么，然后把它给回来的东西直接上线，而不逐行阅读代码。这个词在 2025 年初走红，但这套工作流比这个名字更早出现：下提示词、跑一下、看到能用、再下提示词。Lovable、Cursor、Claude Code、Replit、Bolt 和 v0 这类工具，让一个非工程师能在一个下午里从想法走到可点击的 App。这一部分是真实的，对于原型、内部工具，以及验证一个想法是否值得做，它确实有用。

麻烦从一个 vibe-coded 的 App 撞上真实用户、真实金钱或真实数据的那一刻开始。LLM 优化的是满足提示词、能在演示里跑起来的代码。它不会优化提示词里没人提到的那些东西：授权检查、输入校验、密钥管理、限流、错误处理、回归测试套件。而这恰恰是把演示和 [可上生产](/zh/glossary/production-ready/) 的软件区分开来的东西，也恰恰是模型会漏掉的东西，除非你知道要去要求它，而一个非工程师按定义就不知道。

举个例子。一位创始人用一个周末 vibe-code 出一个 SaaS 仪表盘。它有登录、有数据库、有干净的 UI，演示起来非常漂亮。它没有的，是一个服务端检查，确保用户 A 读不到用户 B 的记录。登录能用，所以感觉很安全。但任何已登录的用户都能改一下 URL 里的 ID，读到任意其他客户的数据。从没人要求模型强制按租户授权，所以它没做，演示里也没有任何东西暴露这个缺口。这是 [vibe-coded 软件](/zh/glossary/vibe-coded-software/) 里最常见的严重缺陷，而且在有人，或者某个监管机构，发现它之前，它始终是隐形的。

诚实的取舍：vibe coding 确实更快做出能跑的演示，假装不是这样就是不诚实。代价是，这份速度来自跳过了工程里那些在失败之前没有可见回报的部分。对一个用完即弃的原型来说这是好买卖，对任何存有客户数据的东西来说则是糟糕的买卖。错误不在于用这些工具。错误在于把演示当成产品，然后把它上线。 [AI 生成的代码](/zh/glossary/ai-generated-code/) 本身并不比手写代码差，但它会悄无声息地累积 [技术债](/zh/glossary/technical-debt/) ，并且每次都跳过同样的安全工作。

Wavect 的立场很简单：原型可以 vibe-code，然后在真实用户到来之前，做一遍结构化的生产就绪检查。这一遍不是凭感觉。它就是我们对任何代码都施加的同一套纪律：在重要的逻辑上做 [TDD](/zh/glossary/tdd/) 、每个端点都做授权、把密钥从客户端拿掉，以及一条在每次改动时都跑这些检查的 [CI/CD](/zh/glossary/ci-cd/) 流水线。我们在 [Software Quality Assurance](/zh/services/software-quality-assurance/) 下做这件事。工具是好的。它们只是不知道自己漏掉了什么，而在有人读它之前，你也不知道。

**在软件项目中何时最关键。** 在一个 vibe-coded 原型不再是用完即弃、开始走向真实用户、真实金钱或真实数据的那一刻。那正是模型略过的部分，变成会让你被泄露的部分。

**创始人通常会搞错什么。** 他们把演示当成产品并发布出去。Happy path 能跑，于是感觉安全，但提示词里没有任何东西要求授权、校验或密钥管理，所以这些一概没有。

**Wavect 如何处理。** 原型可以 vibe-code，然后在上线前跑一遍结构化的生产就绪检查：每个端点都授权、密钥移出客户端、一套回归套件、一道 CI/CD 闸门。 [从 vibe-coded 原型到生产](/zh/software-development-guide/vibe-coded-prototype-to-production/) 指南一步步讲了这种加固。

另见 [Vibe-Coded 软件](/zh/glossary/vibe-coded-software/) / [AI 生成的代码](/zh/glossary/ai-generated-code/) / [可上生产（Production-Ready）](/zh/glossary/production-ready/) / [TDD](/zh/glossary/tdd/) / [Technical Debt](/zh/glossary/technical-debt/) / [SDLC](/zh/glossary/sdlc/) / [CI/CD](/zh/glossary/ci-cd/)

[阅读完整定义 →](/zh/glossary/vibe-coding/)

065 / 073 methodology [#](#vibe-coded-software)

一款大部分由 AI 工具生成的 App，其安全关键路径没有任何人读过。它演示得很干净，崩坏得很可预测：缺失授权、未校验的输入、泄露的密钥。最常见的严重缺陷，是一个能用的登录界面，却没有任何服务端检查阻止用户 A 读取用户 B 的数据。

Vibe-coded 软件是 [vibe coding](/zh/glossary/vibe-coding/) 的产物：一款大部分由 AI 工具构建的应用，其中对安全要紧的部分没有任何人读过。它的定义不在于是 AI 生成的。它的定义在于，在那些一旦出错就会损失真实金钱、真实数据或造成真实泄露的路径上，缺少人工评审。大量 [AI 生成的代码](/zh/glossary/ai-generated-code/) 是经过评审、加固、完全安全的。Vibe-coded 软件是其中没有做这些的那个子集。

它的标志性特征是：演示得干净，崩坏得可预测。演示干净，是因为模型非常擅长让 happy path 跑起来，也就是你在演示里走的那条路。崩坏可预测，是因为故障每次都聚集在同样的那几个地方：只检查你是否登录、却不检查你是否有权看这条记录的授权；被信任而不是被校验的输入；硬编码或被发到浏览器的密钥；没有限流；除了一个通用 catch 之外没有错误处理。审计过一个 vibe-coded App 的人，在打开下一个之前就能猜到它的发现项。

举个例子，最典型的那个。一款订票 App 有一个干净的登录。进去之后，App 从 /api/bookings/1234 拉取你的订单。把 1234 改成 1235，你就看到了别人的订单，他的姓名、他的地址、他的支付凭证。登录让人感觉安全，所以没人去查。服务器从未验证过登录用户是否拥有 1235 这张订单。这叫做对象级授权失效（broken object level authorization）漏洞，它是 vibe-coded 软件里最常见的严重缺陷，因为演示从不会去走"一个用户去够另一个用户数据"这种情形。

诚实的取舍：vibe-coded 软件确实更便宜、更快产出，对一个原型来说这恰恰正确。代价是，省下的成本被提前了，而账单晚些才到，形式可能是一次泄露、一起 GDPR 事件，或一次重写。指出这一点不是反 AI 的清高。一旦把缺失的那 10% 补回来，代码可以完全没问题。错误在于把那 90% 上线，并假定演示已经证明了另外那 10% 的存在。

Wavect 在 [Software Quality Assurance](/zh/services/software-quality-assurance/) 下，正是按这个画像来审计 vibe-coded 软件。我们先读授权路径，因为最糟糕、最常见的漏洞就住在那里，然后是输入校验、密钥和错误处理，再补上回归测试套件，以及那道阻止下一次改动重新捅开窟窿的 [CI/CD](/zh/glossary/ci-cd/) 闸门。这不是重写。这是把工具留下的 [技术债](/zh/glossary/technical-debt/) 变得可见，然后偿还其中会伤到你的那一部分。

**在软件项目中何时最关键。** 当你有一个演示得很干净的应用、却没人读过授权路径时。决定性的风险不是代码差，而是在「出错就会赔上金钱、数据或一次泄露」的地方缺了人工审查。

**创始人通常会搞错什么。** 他们发布演示证明过的那 90%，并假设演示也证明了另外 10%。缺失的 10%，授权、校验、密钥，正是演示从不触及的那部分。

**Wavect 如何处理。** 我们按可预测的失败画像来审计，先做授权，因为最糟的漏洞住在那里，然后补上回归套件和阻止窟窿重开的 CI/CD 闸门。 [从 vibe-coded 原型到生产](/zh/software-development-guide/vibe-coded-prototype-to-production/) 指南讲清了什么可保留、什么需重建。

另见 [Vibe Coding（凭感觉编程）](/zh/glossary/vibe-coding/) / [AI 生成的代码](/zh/glossary/ai-generated-code/) / [可上生产（Production-Ready）](/zh/glossary/production-ready/) / [TDD](/zh/glossary/tdd/) / [Technical Debt](/zh/glossary/technical-debt/) / [SDLC](/zh/glossary/sdlc/) / [CI/CD](/zh/glossary/ci-cd/)

[阅读完整定义 →](/zh/glossary/vibe-coded-software/)

066 / 073 methodology [#](#ai-generated-code)

由 LLM 编程工具写出、而非工程师敲出的代码。它本身并不更差，但它每次都跳过同样的东西，所以在真实金钱或用户接触它之前，需要一遍结构化的生产就绪检查。

AI 生成的代码，是由 LLM 编程工具（Copilot、Cursor、Claude Code、Lovable 等等）产出、而不是手敲出来的代码。需要先说清楚的是：它本身并不比人类代码差。在 happy path 上，它往往比一个赶工的工程师在周五傍晚六点写出来的东西更干净、更地道、注释更好。把所有 AI 生成的代码当垃圾，和把它们全当成可上生产，是同样错误的。

真正值得了解的特性是：AI 生成的代码每次以同样的方式失败。LLM 没有糟糕的一天，没有截止日期，也没有怨气。它有的是一个训练分布和一个提示词。所以缺口是系统性的，而非随机的：它会漏掉提示词没提到的授权检查，会信任提示词没标记为恶意的输入，会因为提示词描述的是成功路径而把错误处理写得很单薄。系统性的缺口是好消息，因为系统性的缺口可以用一份结构化的清单来堵上，而不必指望评审者碰巧注意到。

举个与人类 bug 的区别。一个疲惫的工程师可能会随机地在二十个端点里漏掉某一个的校验，而评审者也恰好略过了它。而你让 LLM 去构建二十个端点，它倾向于在这二十个上以同样方式处理校验，所以如果错，它就一致地错，懂这个模式的评审者一次就能抓住全部二十个。工作不是"找出那个随机错误"。工作是"确认模型做出的系统性决定，并在生产需要更多的地方推翻它"。这比追着人类那种一次性的疏忽要更快、更可靠。

诚实的取舍：AI 生成的代码把精力从写转移到了评审上，而这只有在评审真的发生时才省时间。跳过评审，你得到的就是带着更漂亮提交历史的 [vibe-coded 软件](/zh/glossary/vibe-coded-software/) 。工具让写代码几乎免费，这诱使团队跳过那唯一一个从来不是瓶颈的步骤，即抓系统性缺口的那遍 [TDD](/zh/glossary/tdd/) 与安全检查。只有当你把省下的一部分投回到那个你以为不再需要的评审上时，省下的时间才是真实的。

Wavect 把 AI 生成的代码当作初稿，在上线前需要一遍已知的、可重复的生产就绪检查，这件事在 [Software Quality Assurance](/zh/services/software-quality-assurance/) 下完成。因为缺口是可预测的，这一遍很快：每个端点都做授权、每个输入都做校验、把密钥从客户端拿掉、处理错误，然后补上一套回归测试套件，以及一道 [CI/CD](/zh/glossary/ci-cd/) 闸门，好让下一个提示词不会悄悄重新捅开一个窟窿。这样做出来，AI 生成的代码就是真实的生产力收益，而不是一堆沉默的 [技术债](/zh/glossary/technical-debt/) 。

**在软件项目中何时最关键。** 每当一个 LLM 工具写了将被真实用户看到的代码中相当一部分时。它本身并不比手写代码更差，但它每次都以同样的方式失败，所以缺口是系统性的，不是随机的。

**创始人通常会搞错什么。** 他们以为工具让写代码几乎免费，于是跳过审查，而审查恰恰是那个从来不是瓶颈的步骤。跳过它，你就得到一份提交历史更漂亮的 vibe-coded 软件。

**Wavect 如何处理。** 我们把 AI 生成的代码当作初稿，让它走一遍已知、可重复的生产就绪检查；因为缺口可预测，这一遍很快。 [从 vibe-coded 原型到生产](/zh/software-development-guide/vibe-coded-prototype-to-production/) 指南描述了这种加固的实操。

另见 [Vibe Coding（凭感觉编程）](/zh/glossary/vibe-coding/) / [Vibe-Coded 软件](/zh/glossary/vibe-coded-software/) / [可上生产（Production-Ready）](/zh/glossary/production-ready/) / [TDD](/zh/glossary/tdd/) / [Technical Debt](/zh/glossary/technical-debt/) / [SDLC](/zh/glossary/sdlc/) / [CI/CD](/zh/glossary/ci-cd/)

[阅读完整定义 →](/zh/glossary/ai-generated-code/)

067 / 073 methodology [#](#production-ready)

你可以把它摆在真实用户面前、而不会在凌晨三点被告警叫醒的软件：每个端点都有授权、输入经过校验、客户端里没有密钥、有错误处理、有回归套件、有可观测性、有回滚。一个能跑的演示，并不等于可上生产。

可上生产，是"演示时能用的软件"和"你睡着、一个陌生人在错误地使用它时仍然能用的软件"之间的区别。它不是一种感觉，也不是你宣布的一个里程碑。它是一份具体的清单，而演示与可上生产之间的差距，恰恰就是那张清单上的东西，这些东西在失败的那一刻之前都没有可见回报。

把清单直白地说出来：每个端点都做授权，而不只是登录处做认证；对一切跨越信任边界的东西做输入校验；客户端打包里、仓库里都没有密钥；错误处理是失败时安全（fail-safe），而不是泄露一段堆栈跟踪；一套在每次改动时都跑的回归套件，好让下一个修复不会重新捅开旧 bug；可观测性，让你从仪表盘而不是从一个暴怒的客户那里得知出事；以及一条以分钟计的回滚路径。少了其中任何一项，你拥有的就是穿着生产戏服的演示。

举个例子。同一款订票 App 的两个版本，在演示里看起来一模一样。版本 A 在只检查你是否登录之后，按 ID 返回一张订单。版本 B 会检查登录用户是否真的拥有这张订单，校验 ID 格式，记录这次访问，并在某个账号开始枚举 ID 时告警。一样的界面、一样的 happy path、一样的演示。版本 A 是一场等着某个好奇者的泄露；版本 B 可上生产。用户可见的产品是相同的，这恰恰是为什么"它在演示里能用"完全说明不了它是否可上生产。

诚实的取舍：做到可上生产要花真实的时间，而其中大部分时间换不来任何客户会看到或感谢你的东西。当一个演示看起来已经做完时，这确实让人沮丧，也正是团队过早上线的唯一原因。对任何存有用户数据的东西来说，这笔交易并非可选，但诚实地讲，这份账单感觉就像纯粹的额外开销，直到凌晨三点的告警或那封 GDPR 信件，把它变成你花过的最便宜的钱。对一个真正用完即弃的原型来说，跳过它才是正确的决定。

Wavect 的生产就绪检查，是从一个 [vibe-coded](/zh/glossary/vibe-coded-software/) 或 [AI 生成](/zh/glossary/ai-generated-code/) 的原型，通往一个你能收费的东西的桥梁，这在 [Software Quality Assurance](/zh/services/software-quality-assurance/) 下进行。我们按影响半径的顺序来处理清单：先做授权，因为最糟糕的漏洞住在那里，然后是校验、密钥、错误处理，再然后是 [TDD](/zh/glossary/tdd/) 回归套件，以及让它保持绿色的 [CI/CD](/zh/glossary/ci-cd/) 闸门。目标不是完美。目标是没有人会在凌晨三点，因为某件你本可以在上线前读一读的事情，被叫醒。

**在软件项目中何时最关键。** 就在真实用户到来之前。生产就绪是「在演示里能跑的软件」与「你睡着、陌生人乱用时仍能跑的软件」之间那条具体的界线。

**创始人通常会搞错什么。** 他们把它当成一种感觉或一个可以宣布的里程碑，而不是一份要逐项清掉的清单。大部分工作买不到任何客户看得见的东西，这正是团队过早上线的原因，直到凌晨三点的告警把它变成花得最值的钱。

**Wavect 如何处理。** 我们按影响半径的顺序处理清单，先授权，再校验、密钥、错误处理，然后是回归套件和 CI/CD 闸门。 [上线前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 和 [从 vibe-coded 原型到生产](/zh/software-development-guide/vibe-coded-prototype-to-production/) 指南覆盖了完整的这一遍检查。

另见 [Vibe Coding（凭感觉编程）](/zh/glossary/vibe-coding/) / [Vibe-Coded 软件](/zh/glossary/vibe-coded-software/) / [AI 生成的代码](/zh/glossary/ai-generated-code/) / [TDD](/zh/glossary/tdd/) / [Technical Debt](/zh/glossary/technical-debt/) / [SDLC](/zh/glossary/sdlc/) / [CI/CD](/zh/glossary/ci-cd/)

[阅读完整定义 →](/zh/glossary/production-ready/)

068 / 073 methodology [#](#scrum)

一种敏捷框架，将工作组织成固定长度的冲刺，并通过明确的角色、事件和工件，让团队在紧凑的循环中持续交付和检视。

Scrum 是 [敏捷](/zh/glossary/agile/) 原则的一种实现，有三个角色、三个工件和少数几个事件。产品负责人决定构建什么以及按什么顺序构建。 [Scrum Master](/zh/glossary/scrum-master/) 清除阻碍并保护流程。开发人员负责构建。工件包括产品待办列表（所有可能被构建的内容，通常写成 [用户故事](/zh/glossary/user-story/) ）、冲刺待办列表（本次冲刺承诺的内容）和增量（实际交付的内容）。事件包括冲刺规划、每日站会、冲刺评审和回顾会议。

Scrum 真正有帮助的地方：在那些难以保持专注和可见性的团队。固定的冲刺迫使团队做出真正的承诺，评审迫使团队进行真正的演示，回顾迫使团队审视自己的流程而不是忽视它。对于一个从未按节奏交付过的团队来说，Scrum 是一个有用的脚手架。

它沦为表演的地方：当事件存活下来但实质却消亡了。一个变成向经理汇报状态的站会。一个没有可运行软件可展示的评审。一个每两周都产出同样三条行动项却从不落实的回顾。许多「Scrum」团队执行着仪式，却得不到任何价值。如果你开了会却无法演示一个可运行的增量，那你拥有的不是 Scrum，而是一个开会的习惯。

那个开销陷阱，举个实际例子：一个五人团队照着书本采用 Scrum，最后每两周就要做一次冲刺规划、每日站会、待办列表梳理会、冲刺评审和回顾。在这个规模的团队上，那套仪式负荷一周能吃掉每人差不多大半天的时间，而它换来的规划精度是浪费的，因为一个五人团队本来就知道每个人在做什么。这个框架是为了协调那些已经失去这种可见性的团队而设计的；把整套都强加到一个从未失去它的团队身上，纯属交税。修法不是抛弃那些反馈回路（保留演示和回顾），而是砍掉那些在解决你并不存在的问题的协调仪式。

Wavect 的坦诚看法：Scrum 是一个不错的入门框架，却是一个糟糕的宗教。保留那些创造反馈的部分，舍弃那些制造负担的部分。大多数成熟团队在纪律内化之后，都会漂向更轻量的方式，往往更接近 [Kanban](/zh/glossary/kanban/) 。

另见 [Agile](/zh/glossary/agile/) / [Sprint](/zh/glossary/sprint/) / [Kanban](/zh/glossary/kanban/) / [Scrum Master](/zh/glossary/scrum-master/) / [User Story](/zh/glossary/user-story/)

[阅读完整定义 →](/zh/glossary/scrum/)

069 / 073 methodology [#](#kanban)

一种基于流动的方法，在看板上可视化工作，限制同时进行的工作量，并仅在有产能时拉取新工作，没有固定的迭代。

Kanban 有两个核心理念：让工作可见，以及限制在制品。你把每一项工作放到一个看板上，看板按每个阶段分列（待办、进行中、评审、完成），并对每个活动列同时能容纳的工作项数量设上限。当一列已满时，没人开始新工作，直到有东西移出去。这个上限正是全部要点：它迫使团队在开始更多工作之前先完成手头的工作。

与 [Scrum](/zh/glossary/scrum/) 的对比在于节奏。Scrum 把工作分批放进固定的 [冲刺](/zh/glossary/sprint/) ，并在每个边界处重新规划。Kanban 没有冲刺。工作随着产能腾出而被持续拉取，你可以在任何时刻改变优先级，无需等待一个冲刺结束。没有承诺仪式，没有冲刺评审，没有人为的两周方框。两者都是同一个 [敏捷](/zh/glossary/agile/) 目标的实现：紧凑的反馈，以及根据证据改变方向的能力。

当工作以不可预测且由中断驱动的方式到来时（支持、运维、平台团队），或当团队成熟到冲刺脚手架已变成纯粹负担时，选择 Kanban。当团队需要节奏和强制评审来建立交付纪律时，或当干系人需要可预测的演示节奏来做规划时，选择 Scrum。

在制品限制对一个团队到底起什么作用，举个实际例子：一个五人团队，把「进行中」这一列封顶到三，意味着有时会有两个人手头没有自己的事可开始。本能的反应是觉得这是浪费、工程师闲着了。其实恰恰相反。这两个人现在被迫去帮忙完成已经在跑的那三件事、去评审队友的工作、或去和人结对攻克那个阻塞，而不是再打开第四个任务、把团队摊得更薄。一列满了带来的那点不适，正是这个机制在起作用：它把「人人都忙、什么都没交付」变成「在跑的事更少、事情真的被做完」。无法容忍那点短暂闲置的团队，会悄悄把上限调高、直到它不再约束任何东西，然后纳闷为什么吞吐量没有改善。

坦诚的版本：在制品限制才是价值所在，而它也正是团队悄悄忽视的部分。一个没有在制品限制的 Kanban 看板，只是一份多了几列的待办清单。如果团队同时开了五件事却一件都没完成，那么限制才是解药，而不是一块更大的看板。

另见 [Scrum](/zh/glossary/scrum/) / [Agile](/zh/glossary/agile/) / [Sprint](/zh/glossary/sprint/)

[阅读完整定义 →](/zh/glossary/kanban/)

070 / 073 methodology [#](#technical-debt)

今天走捷径所带来的未来成本，会以交付变慢的形式偿还，直到捷径被修复为止。有时是聪明的交易，有时是无意的烂摊子，最危险的是没人看得见它。

技术债是一个比喻，而且是个好比喻。当你为了更快交付而走捷径时（用一个快速的临时方案代替干净的设计，用一个硬编码的值代替配置系统），你现在借来时间，以后则以利息的形式偿还：那块区域里每一次未来的改动都会更慢、更冒险、更让人烦。和金融债务一样，它并不自动是坏事。它是一种工具。

有意承担债务往往是正确的决定。在产品市场契合之前，速度胜过优雅，因为你构建的大部分东西反正都会被丢弃。为一个六个月后可能不复存在的产品打造一座无瑕的架构，本身就是一种浪费，而这正是交付一个 [MVP](/zh/glossary/mvp/) 的全部逻辑。正确的做法常常是走捷径、交付、学习，然后在你确定这东西值得保留之后再偿还债务。

危险不在于债务，危险在于看不见的债务。有意的、有记录的债务（「我们把这个硬编码了，这里有在扩展前修复它的工单」）是一项被管理的负债，而一条健康的 [CI/CD](/zh/glossary/ci-cd/) 流水线加上一套清醒的 [SDLC](/zh/glossary/sdlc/) ，正是在它复利之前把它暴露出来的东西。没有记录、没人决定要承担、只是在匆忙和人员流动中堆积起来的债务，才是悄悄绞杀代码库的烂摊子。速度下降，没人说得清原因，每一次估算都翻倍。等它在指标中变得可见时，利息已经复利累积了一年。

Wavect 的立场：债务是一种有意的权衡，而不是道德上的失败。我们乐于承担债务来赶上某个时间窗口，并且会准确写下我们承担了什么以及偿还它要花多少代价。我们拒绝跳过的那场对话，是有人正在付利息而没人为这笔贷款命名的那一场。看看我们的 [全栈开发工作](/zh/services/software-development/) ，了解我们如何让这种权衡保持明确。

**在软件项目中何时最关键。** 一直都在，但在上线前和扩张时咬得最狠，那时积累的捷径会变成更慢的交付，和谁都解释不清的、翻倍的估算。

**创始人通常会搞错什么。** 他们把所有债务都当成坏事而恐慌，或者一直忽视到它变得不可见。危险从来不是有意、有记录的债务；而是因赶工和人员流动堆积起来、没人选择也没人看得见的烂摊子。

**Wavect 如何处理。** 我们为赶上某个时间窗口而有意承担债务，并准确写下承担了什么、偿还要花多少。 [上线前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 正是我们把那些原本会悄悄上线的债务暴露出来的地方。

另见 [SDLC](/zh/glossary/sdlc/) / [CI/CD](/zh/glossary/ci-cd/) / [MVP](/zh/glossary/mvp/)

[阅读完整定义 →](/zh/glossary/technical-debt/)

071 / 073 methodology [#](#devops)

一种文化和一套自动化实践，将开发与运维融合在一起，让同一个团队构建、交付并运行软件，并让反馈从生产环境快速回流到代码。

DevOps 起初是对一种特定功能失调的回应：开发人员把代码越过一堵墙扔给一个独立的运维团队，出问题时运维被指责，而编写软件与运行软件之间的反馈回路被打断了。DevOps 弥合了这个回路。构建软件的团队也负责交付和运行它，运行某物的痛苦会直接回流到能够修复它的人那里。

在实践中，这种文化由自动化来支撑： [CI/CD](/zh/glossary/ci-cd/) 让改动安全且频繁地流入生产环境， [持续交付](/zh/glossary/continuous-delivery/) 的纪律让每一个构建都是可发布的，基础设施即代码让环境可复现而不是手工搭建的「雪花」，可观测性（日志、指标、追踪、告警）让团队看清生产环境实际在做什么。这些工具单独哪一个都不是 DevOps。它们是让这种文化得以存续的东西。

「DevOps 工程师」这个职位头衔在很大程度上是个误称，而且很说明问题。DevOps 不是一个你雇来坐在开发和运维之间的角色，那只是用一个新名字重建了那堵墙。大多数「DevOps 工程师」招聘实际想要的，是一名构建其他开发人员所用自动化的平台或基础设施工程师。人有用，标签贴错了。如果你的组织有一个负责部署、好让开发人员不必动手的 DevOps 团队，那你拥有的是换了招牌的运维，而不是 DevOps。

「你构建它，你运行它」按设计意图奏效的样子，举个实际例子：一名工程师周四上线了一个改动，周五凌晨两点因为它引起一处缓慢的内存泄漏而被呼叫，于是在凌晨那几个小时里修自己的代码。那种难受只发生一次。它同时也是史上最有效的代码评审制度，因为那名工程师再也不会上线那一类 Bug，而且下一次设计东西时，他会去想它在凌晨两点的表现。当一个独立的运维团队替他吸收掉那份痛苦时，那个本来能阻止下一次泄漏的人，永远感受不到上一次的后果，于是同样的错误会无限期地复发。呼叫不是惩罚，它是反馈回路。

Wavect 的看法：DevOps 是一种工作方式，而不是一个部门。我们构建那种让小团队能够端到端地负责自己软件的自动化，并把「你构建它，你运行它」当作默认值。看看我们的 [全栈开发工作](/zh/services/software-development/) ，了解这在实践中如何展开。

另见 [CI/CD](/zh/glossary/ci-cd/) / [Continuous Delivery](/zh/glossary/continuous-delivery/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/devops/)

072 / 073 methodology [#](#waterfall)

一种顺序式开发模型，每个阶段（需求、设计、构建、测试、部署）在下一个阶段开始之前完成。对范围固定且充分理解的工作很扎实，对产品探索则很糟糕。

Waterfall 把一个项目作为一连串有序的阶段来执行：先收集所有需求，然后设计整个系统，然后构建它，然后测试它，然后部署它。每个阶段产出一份签署确认的文档，并在下一个阶段开始之前完成。它的吸引力显而易见：你预先就知道计划、成本和日期，而且所有人在写下一行代码之前都达成一致。

它对某些工作仍然有正当的适用之处。当范围真正固定且被充分理解时，当监管方要求预先的文档和可追溯性时，或当你在构建硬件、金属切下后无法廉价迭代时，顺序式阶段就是诚实的模型。把这样的项目假装成「敏捷」，只是把计划藏了起来，而不是把它去掉。

合同这一面，是 Waterfall 与敏捷碰撞得最具体的地方。在奥地利和德国法律下，一份固定价格的 Werkvertrag 需要一个明确的交付物来绑定供应商，这会自然地把项目推向一个瀑布式、被完整规格化的范围。真正迭代的工作，也就是你预期需求会随学习而变化的那种，更适合 Dienstvertrag 或 Retainer。当创始人既想要固定价格的法律确定性、又想要敏捷的灵活性时，麻烦就来了：这两者朝相反方向拉扯。诚实的解法通常是先做一段固定价格的发现，把范围钉到足以定价的程度，然后用剩余不确定性实际所需的那种边界渗透度去跑构建。

它在产品探索上失败得很惨。致命的假设是，你能在任何用户接触它之前就预先把正确的产品规范定下来。你几乎永远做不到。等到构建阶段结束时，几个月前收集的需求已经有一部分是错的，而 Waterfall 没有廉价的办法在测试阶段之前发现这一点，那时改动任何东西都很昂贵。你得到的是一个符合规范却错失需求的产品。

与 [敏捷](/zh/glossary/agile/) 诚实的区分：Waterfall 把所有决策前置，并赌它们是对的。敏捷（无论是以 [Scrum](/zh/glossary/scrum/) 还是一种更轻量的流动来跑）把决策分散到整个工作过程中，并赌早期反馈会抓住错误的决策。无论哪种，两者都只是对同一组底层 [SDLC](/zh/glossary/sdlc/) 阶段所做的排序选择。对于任何你还不确切知道该构建什么的事情，这个赌注偏向敏捷。对于任何答案真正已知且固定的事情，Waterfall 的可预测性是一个优点，而不是缺陷。

另见 [Agile](/zh/glossary/agile/) / [Scrum](/zh/glossary/scrum/) / [SDLC](/zh/glossary/sdlc/)

[阅读完整定义 →](/zh/glossary/waterfall/)

073 / 073 methodology [#](#user-story)

一段从用户视角讲述功能的简短描述，采用「作为[角色]，我想要[目标]，以便[收益]」的形式，用来捕捉意图而非技术规范。

用户故事从想要它的那个人的视角捕捉一块价值，通常采用「作为[角色]，我想要[目标]，以便[收益]」的格式。它是大多数 [敏捷](/zh/glossary/agile/) 团队用来填充 [冲刺](/zh/glossary/sprint/) 待办列表的单元。这个格式不是为形式而设的官僚主义。「作为」迫使你说出究竟是谁想要这个，「以便」迫使你陈述为什么，而这正是团队会跳过、然后构建出错误东西的那一部分。故事是一次对话的占位符，而不是一份合同。

好的故事往往满足 INVEST 标准：Independent（可以独立构建）、Negotiable（细节在你讨论之前都是开放的）、Valuable（交付用户或买家在意的东西）、Estimable（团队可以估算它）、Small（能装进一次迭代）和 Testable（你能判断它何时完成）。大多数故事在后两项上垮掉：太大而无法完成，或写得太含糊以至于没人说得清「完成」是什么意思。

验收标准是故事变得可测试的途径，而用 [BDD](/zh/glossary/bdd/) 的 Given/When/Then 形式来写它们是最干净的办法。它们是故事被接受所必须满足的具体条件，在工作开始之前就写好。「作为用户我想要重置我的密码」是一种意图。验收标准（重置链接在一小时后失效、无效令牌显示清晰的错误、成功重置后让用户登录）才是团队实际据以构建和测试的东西。

常见的反模式是那种伪装成故事的任务。「作为开发人员我想要给订单表加一个索引」穿着用户故事的戏服，但既没有用户也没有收益，只是一个戴着帽子的工程任务。跟踪它没问题，但它不是用户故事，而把技术任务伪装成故事会悄悄抹去这个格式本应保护的用户视角。

另见 [Agile](/zh/glossary/agile/) / [Sprint](/zh/glossary/sprint/) / [BDD](/zh/glossary/bdd/) / [Scrum](/zh/glossary/scrum/)

[阅读完整定义 →](/zh/glossary/user-story/)

// 03

## 这份术语表不是什么

- 它不是营销词典。我们不会为了让 Wavect 看起来更好而重新定义常用词。
- 它不是大而全。我们只覆盖那些真正出现在我们合同与你 BP 里的 72 个词。
- 它不是静态的。当一个词在市场上的含义发生变化时（这经常发生），我们就更新条目。

// 04

## 常见问题

### Wavect 为什么要发布术语表？

因为第一通电话里有一半的问题不是「你们能不能做」，而是「X 和 Y 有什么区别」。一份公开参考能为双方节省时间，也能让合同谈判更快推进。

### 更新到什么程度？

每个词在 schema 里都带 `lastReviewed` 日期，并在深度页可见。我们至少每季度通读一次整份术语表，市场用法变化时即更新条目。

### 可以单独链接某一个词吗？

可以。每个词条都有自己的深度页，例如 `/zh/glossary/ctpo/` 。这就是用于链接或引用的规范 URL。

### 这是 AI 写的吗？

不是。每条定义由 Kevin Riedl 撰写，Christof Jori 复核，我们其中之一对措辞有异议时再改。我们允许 LLM 索引这一页（这正是目的），但不让它来撰写。

### 你们接受建议吗？

接受。把缺失的词或你认为有误的定义发到 [office@wavect.io](mailto:office@wavect.io) 。每一条我们都会看。

关于这些定义

这些定义反映了 Wavect 在自家合同与项目中如何使用这些词。其他公司可能用法不同。若你发现某条定义已不再符合市场共识，欢迎来信。 [office@wavect.io](mailto:office@wavect.io)

## 还有词没说清楚？

针对这里任何一条定义，把你的真实场景发过来。我们会告诉你哪一条适用于你，以及哪一条是供应商在向你推销错形态的合同。

## Structured Data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@id": "https://wavect.io/#organization",
      "@type": [
        "Organization",
        "ProfessionalService",
        "LocalBusiness"
      ],
      "employee": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "founder": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "legalRepresentative": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "name": "Wavect GmbH",
      "subjectOf": {
        "@id": "https://wavect.io/verified-claims.json#dataset",
        "@type": "Dataset",
        "creator": {
          "@id": "https://wavect.io/#organization",
          "@type": [
            "Organization",
            "ProfessionalService",
            "LocalBusiness"
          ]
        },
        "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.",
        "inLanguage": "en",
        "isAccessibleForFree": true,
        "license": "https://creativecommons.org/licenses/by/4.0/",
        "name": "Wavect verified publication claims",
        "url": "https://wavect.io/verified-claims.json"
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/team/kevin-riedl/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Kevin Riedl",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796365",
        "https://www.linkedin.com/in/wsdt",
        "https://github.com/wsdt"
      ],
      "url": "https://wavect.io/team/kevin-riedl/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/team/christof-jori/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Christof Jori",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796367",
        "https://www.linkedin.com/in/jocr77/",
        "https://github.com/jo-chris"
      ],
      "url": "https://wavect.io/team/christof-jori/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/#website",
      "@type": "WebSite",
      "inLanguage": [
        "en",
        "de",
        "es",
        "zh"
      ],
      "name": "Wavect",
      "potentialAction": {
        "@type": "SearchAction",
        "query-input": "required name=search_term_string",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://wavect.io/search/?q={search_term_string}"
        }
      },
      "publisher": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      },
      "url": "https://wavect.io/"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@id": "https://wavect.io/zh/glossary/#termset",
      "@type": "DefinedTermSet",
      "description": "我们在网站上提到的每一种角色、合作模式、技术与方法的定义。由真正做这份工作的运营者撰写，用一种创始人、CFO 或董事会成员当天就能直接使用的语言。",
      "hasDefinedTerm": [
        {
          "@id": "https://wavect.io/zh/glossary/ctpo/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Chief TPO"
          ],
          "description": "由一位运营者同时承担技术与产品路线图的负责人，适用于把这两个 C-level 拆成两个人雇用太慢或太贵的阶段。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "CTPO",
          "termCode": "ctpo",
          "url": "https://wavect.io/zh/glossary/ctpo/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/cto/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "对技术选型、工程交付与会出现在董事会议程上的技术风险负责的高管。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "CTO",
          "termCode": "cto",
          "url": "https://wavect.io/zh/glossary/cto/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/cpo/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "对要做什么、不做什么以及产品最终是否能推动业务关键指标负责的高管。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "CPO",
          "termCode": "cpo",
          "url": "https://wavect.io/zh/glossary/cpo/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/fractional-cofounder/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Fractional Cofounder",
            "兼职联合创始人"
          ],
          "description": "以联合创始人式合同兼职加入你公司、扎在前线的产品型技术运营者，直到你能负担或吸引到全职接替者。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Fractional Co-Founder",
          "termCode": "fractional-cofounder",
          "url": "https://wavect.io/zh/glossary/fractional-cofounder/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/fractional-cto/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "按定义好的范围、每周 1 至 3 天为你公司服务的资深技术高管，没有股权也没有全职薪水。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Fractional CTO",
          "termCode": "fractional-cto",
          "url": "https://wavect.io/zh/glossary/fractional-cto/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/interim-cto/",
          "@type": "DefinedTerm",
          "alternateName": [
            "过渡期 CTO"
          ],
          "description": "全职但有期限的 CTO，带领工程团队穿过一段过渡期，通常 3 到 12 个月，直到长期人选接手。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Interim CTO",
          "termCode": "interim-cto",
          "url": "https://wavect.io/zh/glossary/interim-cto/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/fractional-cpo/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "按兼职合同负责路线图与客户发现节奏的资深产品高管，无须全职薪水。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Fractional CPO",
          "termCode": "fractional-cpo",
          "url": "https://wavect.io/zh/glossary/fractional-cpo/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/tech-lead/",
          "@type": "DefinedTerm",
          "alternateName": [
            "技术负责人",
            "TL"
          ],
          "description": "团队里最资深的工程师，对团队内部技术决策负责，但不负责更上层的工程组织。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Tech Lead",
          "termCode": "tech-lead",
          "url": "https://wavect.io/zh/glossary/tech-lead/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/engineering-manager/",
          "@type": "DefinedTerm",
          "alternateName": [
            "EM",
            "工程经理"
          ],
          "description": "面向工程师的人事经理，负责绩效、成长、招聘与团队健康。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Engineering Manager",
          "termCode": "engineering-manager",
          "url": "https://wavect.io/zh/glossary/engineering-manager/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/cto-as-a-service/",
          "@type": "DefinedTerm",
          "alternateName": [
            "CTOaaS"
          ],
          "description": "一种订阅形态的合作，卖的是 CTO 级别的决策权，而不在工资单上放一位全职高管。和 Fractional CTO 是同一份工作，不同的包装。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "CTO as a Service",
          "termCode": "cto-as-a-service",
          "url": "https://wavect.io/zh/glossary/cto-as-a-service/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/sow/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Statement of Work",
            "Werkvertrag",
            "工作说明书"
          ],
          "description": "一份签署过的合同，明确指出交付物、价格与截止日期，并在法律上把供应商绑定到这三项之上。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "SoW",
          "termCode": "sow",
          "url": "https://wavect.io/zh/glossary/sow/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/time-and-material/",
          "@type": "DefinedTerm",
          "alternateName": [
            "T&M",
            "按工时计费"
          ],
          "description": "你为投入的工时付费，而不是为交付的成果付费。供应商不承担交付风险；风险全在你这边。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Time & Material",
          "termCode": "time-and-material",
          "url": "https://wavect.io/zh/glossary/time-and-material/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/fixed-price/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Fixed-Price",
            "Fixed Scope"
          ],
          "description": "签署过的 SoW（在奥/德为 Werkvertrag）。供应商在法律上必须按约定的范围、价格与截止日期交付。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "固定价格",
          "termCode": "fixed-price",
          "url": "https://wavect.io/zh/glossary/fixed-price/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/retainer/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "按月循环的合作形式，供应商预留约定的容量，客户按月支付可预测的费用。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Retainer 保留费",
          "termCode": "retainer",
          "url": "https://wavect.io/zh/glossary/retainer/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/discovery-phase/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "短期固定价格合作（Wavect：2 至 3 周，3,500 欧元），结束时交付签署过的架构、里程碑计划与固定价格的 Build 报价。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Discovery Phase 发现阶段",
          "termCode": "discovery-phase",
          "url": "https://wavect.io/zh/glossary/discovery-phase/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/sprint/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "固定长度的工作单元（通常 1 至 2 周），结束时交付并复盘一个可发布的增量。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Sprint",
          "termCode": "sprint",
          "url": "https://wavect.io/zh/glossary/sprint/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/web3/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "建立在公开区块链上的软件，用户把资产与身份保存在自己的钱包里，而不是供应商的数据库里。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Web3",
          "termCode": "web3",
          "url": "https://wavect.io/zh/glossary/web3/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/zero-knowledge/",
          "@type": "DefinedTerm",
          "alternateName": [
            "ZK",
            "ZK 证明",
            "ZK-SNARK",
            "ZK-STARK"
          ],
          "description": "一种密码学技术，可以在不泄露背后数据的前提下，证明某个陈述为真。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Zero-Knowledge",
          "termCode": "zero-knowledge",
          "url": "https://wavect.io/zh/glossary/zero-knowledge/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/homomorphic-encryption/",
          "@type": "DefinedTerm",
          "alternateName": [
            "FHE",
            "Fully Homomorphic Encryption",
            "TFHE",
            "CKKS",
            "同态加密",
            "全同态加密"
          ],
          "description": "一种密码学技术，让服务器可以在从不解密的前提下对加密数据进行计算。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "同态加密",
          "termCode": "homomorphic-encryption",
          "url": "https://wavect.io/zh/glossary/homomorphic-encryption/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/account-abstraction/",
          "@type": "DefinedTerm",
          "alternateName": [
            "ERC-4337",
            "AA"
          ],
          "description": "一种让区块链账户像智能合约一样工作的模式：无 Gas 交易、社交恢复、批量调用、自定义鉴权规则。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Account Abstraction",
          "termCode": "account-abstraction",
          "url": "https://wavect.io/zh/glossary/account-abstraction/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/ai-agents/",
          "@type": "DefinedTerm",
          "alternateName": [
            "AI 智能体",
            "Agentic AI"
          ],
          "description": "一种使用 LLM 决定下一步、调用工具执行决定、并循环直到完成目标的软件形态。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "AI Agents",
          "termCode": "ai-agents",
          "url": "https://wavect.io/zh/glossary/ai-agents/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/mcp/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一种开放协议，让 AI 模型可以安全地连接外部工具与数据源，而无需为每个模型单独写定制集成。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "MCP",
          "termCode": "mcp",
          "url": "https://wavect.io/zh/glossary/mcp/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/rag/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "在运行时把相关上下文注入 LLM Prompt，这些上下文来自你自己的数据，让模型基于你的知识回答，而不是它训练数据里的知识。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "RAG",
          "termCode": "rag",
          "url": "https://wavect.io/zh/glossary/rag/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/smart-contract/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Smart Contract"
          ],
          "description": "运行在区块链上的代码，确定性执行，一经部署便不可更改（除非你设计成可升级）。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "智能合约",
          "termCode": "smart-contract",
          "url": "https://wavect.io/zh/glossary/smart-contract/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/evm/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "在 Ethereum 及数十条复制了它字节码格式的链上执行智能合约的运行时。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "EVM",
          "termCode": "evm",
          "url": "https://wavect.io/zh/glossary/evm/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/solana/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "高吞吐、低手续费的区块链，运行时与 EVM 完全不同。编程模型不同，取舍也不同。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Solana",
          "termCode": "solana",
          "url": "https://wavect.io/zh/glossary/solana/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/lorawan/",
          "@type": "DefinedTerm",
          "alternateName": [
            "LoRa",
            "IoT",
            "Long Range WAN"
          ],
          "description": "低功耗、远距离无线协议，把电池供电的传感器接入互联网，常用于智慧城市与农业 IoT。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "LoRaWAN",
          "termCode": "lorawan",
          "url": "https://wavect.io/zh/glossary/lorawan/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/agile/",
          "@type": "DefinedTerm",
          "alternateName": [
            "敏捷"
          ],
          "description": "一族软件开发实践，重视短迭代、频繁的客户反馈，以及根据交付结果回头调整计划。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Agile",
          "termCode": "agile",
          "url": "https://wavect.io/zh/glossary/agile/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/tdd/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "先写测试。看它失败。写让它通过的最简代码。重构。重复。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "TDD",
          "termCode": "tdd",
          "url": "https://wavect.io/zh/glossary/tdd/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/bdd/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "用业务方能读懂的语言写测试。然后让这些测试通过。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "BDD",
          "termCode": "bdd",
          "url": "https://wavect.io/zh/glossary/bdd/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/mvp/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "能让你判断「这个想法是不是错的」的最小版本。不是「能发布的最小版本」，而是「能教会你东西的最小版本」。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "MVP",
          "termCode": "mvp",
          "url": "https://wavect.io/zh/glossary/mvp/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/pmf/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "市场以你来不及构建的速度把产品从你手里「拉」出去的那个点。在你感受到这股拉力之前，你还没有 PMF。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "PMF",
          "termCode": "pmf",
          "url": "https://wavect.io/zh/glossary/pmf/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/sdlc/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一个软件项目从端到端要走的阶段：发现、设计、构建、测试、部署、运维、退役。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "SDLC",
          "termCode": "sdlc",
          "url": "https://wavect.io/zh/glossary/sdlc/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/ci-cd/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "每一次代码变更都自动构建、测试、准备发布。一些团队再进一步，每一次通过的构建都自动上生产。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "CI/CD",
          "termCode": "ci-cd",
          "url": "https://wavect.io/zh/glossary/ci-cd/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/continuous-delivery/",
          "@type": "DefinedTerm",
          "alternateName": [
            "CD",
            "持续交付"
          ],
          "description": "每一次变更都被自动准备成可发布形态。最后是否真的发布到生产，仍由人来按下那个按钮。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Continuous Delivery",
          "termCode": "continuous-delivery",
          "url": "https://wavect.io/zh/glossary/continuous-delivery/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/vibe-coding/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Vibe Coded",
            "Vibe-Coded"
          ],
          "description": "通过给 AI 工具下提示词来构建软件（Lovable、Cursor、Claude Code、Replit、Bolt、v0），并不加阅读地接受它生成的东西。做出演示很快，上生产很危险，因为模型优化的是能跑起来的代码，不是能扛住真实用户的代码。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Vibe Coding（凭感觉编程）",
          "termCode": "vibe-coding",
          "url": "https://wavect.io/zh/glossary/vibe-coding/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/vibe-coded-software/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一款大部分由 AI 工具生成的 App，其安全关键路径没有任何人读过。它演示得很干净，崩坏得很可预测：缺失授权、未校验的输入、泄露的密钥。最常见的严重缺陷，是一个能用的登录界面，却没有任何服务端检查阻止用户 A 读取用户 B 的数据。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Vibe-Coded 软件",
          "termCode": "vibe-coded-software",
          "url": "https://wavect.io/zh/glossary/vibe-coded-software/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/ai-generated-code/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "由 LLM 编程工具写出、而非工程师敲出的代码。它本身并不更差，但它每次都跳过同样的东西，所以在真实金钱或用户接触它之前，需要一遍结构化的生产就绪检查。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "AI 生成的代码",
          "termCode": "ai-generated-code",
          "url": "https://wavect.io/zh/glossary/ai-generated-code/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/production-ready/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "你可以把它摆在真实用户面前、而不会在凌晨三点被告警叫醒的软件：每个端点都有授权、输入经过校验、客户端里没有密钥、有错误处理、有回归套件、有可观测性、有回滚。一个能跑的演示，并不等于可上生产。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "可上生产（Production-Ready）",
          "termCode": "production-ready",
          "url": "https://wavect.io/zh/glossary/production-ready/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/llm/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一种经过训练以预测下一个 token 的统计模型，这使它在语言任务上出奇地出色，而在任何需要保证正确性的事情上都不可靠。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "LLM",
          "termCode": "llm",
          "url": "https://wavect.io/zh/glossary/llm/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/prompt-engineering/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "编写你发送给 LLM 的指令和上下文，使它产出你真正想要的输出。这是真正的工程，而不是某种魔法咒语。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Prompt Engineering",
          "termCode": "prompt-engineering",
          "url": "https://wavect.io/zh/glossary/prompt-engineering/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/fine-tuning/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "在你自己的示例上继续训练模型以改变它的行为，这对于风格和格式是正确的工具，而对于注入最新事实则是错误的工具。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Fine-Tuning",
          "termCode": "fine-tuning",
          "url": "https://wavect.io/zh/glossary/fine-tuning/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/vector-database/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Embeddings",
            "Vector Search",
            "Vector DB"
          ],
          "description": "一种把文本存储为数值向量的数据库，使你能够按含义而非精确关键词来搜索，它是大多数 RAG 系统所运行的检索引擎。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Vector Database",
          "termCode": "vector-database",
          "url": "https://wavect.io/zh/glossary/vector-database/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/hallucination/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "当 LLM 产出流畅、自信却纯属虚假的输出时，这是模型工作方式的直接后果，无法被完全消除，只能被减少。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Hallucination",
          "termCode": "hallucination",
          "url": "https://wavect.io/zh/glossary/hallucination/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/context-window/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "LLM 一次能够考虑的最大文本量，以 token 计量，也是你为什么不能简单地把整个知识库粘进每个 Prompt 的原因。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Context Window",
          "termCode": "context-window",
          "url": "https://wavect.io/zh/glossary/context-window/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/blockchain/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一个共享的、只可追加的账本，由一组计算机在没有中心运营方的情况下达成共识。任何人都无法悄悄修改历史记录。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Blockchain",
          "termCode": "blockchain",
          "url": "https://wavect.io/zh/glossary/blockchain/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/layer-2/",
          "@type": "DefinedTerm",
          "alternateName": [
            "L2",
            "Rollup",
            "Layer-2"
          ],
          "description": "一条建立在基础区块链之上的链，以低成本、快速地处理交易，然后将证明回传到基础层以获得安全性。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Layer 2",
          "termCode": "layer-2",
          "url": "https://wavect.io/zh/glossary/layer-2/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/defi/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "由公有区块链上的 Smart Contract 而非银行或券商运行的金融服务（交易、借出、借入）。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "DeFi",
          "termCode": "defi",
          "url": "https://wavect.io/zh/glossary/defi/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/dao/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一个通过 Smart Contract 协调的群体，其共享资金和决策由链上投票治理，而不是由董事会和银行账户治理。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "DAO",
          "termCode": "dao",
          "url": "https://wavect.io/zh/glossary/dao/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/nft/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "区块链上一个独一无二、可转让的代币，指向某个特定事物：一项资产的所有权、一项访问权或一条记录。常常是一张 JPEG，有时确实有用。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "NFT",
          "termCode": "nft",
          "url": "https://wavect.io/zh/glossary/nft/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/crypto-wallet/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Self-Custody Wallet",
            "Web3 Wallet"
          ],
          "description": "持有你区块链资产密钥并对交易进行签名的软件。钱包真正存储的是密钥，而不是币本身。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Crypto Wallet",
          "termCode": "crypto-wallet",
          "url": "https://wavect.io/zh/glossary/crypto-wallet/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/stablecoin/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一种旨在保持稳定价值的区块链代币，通常锚定一单位法定货币，让你能在链上交易而不受加密货币价格波动的影响。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Stablecoin",
          "termCode": "stablecoin",
          "url": "https://wavect.io/zh/glossary/stablecoin/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/staff-augmentation/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "你把外部工程师招入自己的团队，在你的管理下、按你的路线图工作。供应商提供人，你提供方向。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Staff Augmentation",
          "termCode": "staff-augmentation",
          "url": "https://wavect.io/zh/glossary/staff-augmentation/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/technical-due-diligence/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Tech DD",
            "Technical DD"
          ],
          "description": "投资人或收购方在一轮融资或收购之前付费进行的独立技术评估：代码、架构、团队、安全、可扩展性以及关键人员风险。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Technical Due Diligence",
          "termCode": "technical-due-diligence",
          "url": "https://wavect.io/zh/glossary/technical-due-diligence/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/proof-of-concept/",
          "@type": "DefinedTerm",
          "alternateName": [
            "PoC"
          ],
          "description": "一个用完即弃的构建，只回答一个问题：这在技术上可行吗。它不是产品、不是 MVP、也不是你交付给用户的东西。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Proof of Concept",
          "termCode": "proof-of-concept",
          "url": "https://wavect.io/zh/glossary/proof-of-concept/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/dedicated-team/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一支完整的外部团队，端到端地拥有一条工作流，配有自己的负责人，按你的路线图工作。供应商负责的是结果，而不仅仅是工时。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Dedicated Team",
          "termCode": "dedicated-team",
          "url": "https://wavect.io/zh/glossary/dedicated-team/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/nearshoring/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Offshoring",
            "Outsourcing"
          ],
          "description": "把开发迁往一个邻近国家、邻近时区的供应商。被宣传的节省是日费率；真实的成本是协调税。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Nearshoring",
          "termCode": "nearshoring",
          "url": "https://wavect.io/zh/glossary/nearshoring/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/scrum/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一种敏捷框架，将工作组织成固定长度的冲刺，并通过明确的角色、事件和工件，让团队在紧凑的循环中持续交付和检视。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Scrum",
          "termCode": "scrum",
          "url": "https://wavect.io/zh/glossary/scrum/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/kanban/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一种基于流动的方法，在看板上可视化工作，限制同时进行的工作量，并仅在有产能时拉取新工作，没有固定的迭代。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Kanban",
          "termCode": "kanban",
          "url": "https://wavect.io/zh/glossary/kanban/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/technical-debt/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "今天走捷径所带来的未来成本，会以交付变慢的形式偿还，直到捷径被修复为止。有时是聪明的交易，有时是无意的烂摊子，最危险的是没人看得见它。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Technical Debt",
          "termCode": "technical-debt",
          "url": "https://wavect.io/zh/glossary/technical-debt/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/devops/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一种文化和一套自动化实践，将开发与运维融合在一起，让同一个团队构建、交付并运行软件，并让反馈从生产环境快速回流到代码。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "DevOps",
          "termCode": "devops",
          "url": "https://wavect.io/zh/glossary/devops/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/waterfall/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一种顺序式开发模型，每个阶段（需求、设计、构建、测试、部署）在下一个阶段开始之前完成。对范围固定且充分理解的工作很扎实，对产品探索则很糟糕。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Waterfall",
          "termCode": "waterfall",
          "url": "https://wavect.io/zh/glossary/waterfall/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/user-story/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一段从用户视角讲述功能的简短描述，采用「作为[角色]，我想要[目标]，以便[收益]」的形式，用来捕捉意图而非技术规范。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "User Story",
          "termCode": "user-story",
          "url": "https://wavect.io/zh/glossary/user-story/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/product-manager/",
          "@type": "DefinedTerm",
          "alternateName": [
            "PM"
          ],
          "description": "负责决定构建什么以及为什么构建的人，并要在所有想构建别的东西的人面前捍卫这些决定。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Product Manager",
          "termCode": "product-manager",
          "url": "https://wavect.io/zh/glossary/product-manager/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/product-engineer/",
          "@type": "DefinedTerm",
          "alternateName": [
            "产品工程师",
            "Full-Stack Product Engineer"
          ],
          "description": "对结果负责、而不是对工单负责的工程师：他与用户交谈，决定构建什么，并亲自交付。一个人闭合了从问题到代码的整个回路。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Product Engineer",
          "termCode": "product-engineer",
          "url": "https://wavect.io/zh/glossary/product-engineer/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/software-architect/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Solutions Architect"
          ],
          "description": "负责软件系统级形态的人：那些难以逆转、代价高昂的重大结构性决策，以及无人认领的非功能性需求。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Software Architect",
          "termCode": "software-architect",
          "url": "https://wavect.io/zh/glossary/software-architect/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/scrum-master/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "其工作是清除障碍、保护团队免受干扰并让流程持续运转的人，而不是管理人员或分派工作。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Scrum Master",
          "termCode": "scrum-master",
          "url": "https://wavect.io/zh/glossary/scrum-master/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/microservices/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "一种把应用拆分成许多个可独立部署的小服务的架构，它以真正的分布式系统复杂性为代价，换来扩展能力和团队独立性。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "Microservices",
          "termCode": "microservices",
          "url": "https://wavect.io/zh/glossary/microservices/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/api/",
          "@type": "DefinedTerm",
          "alternateName": [
            "REST API",
            "REST"
          ],
          "description": "一段软件与另一段软件对话所经由的约定契约，双方都无需知道对方内部是如何运作的。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "API",
          "termCode": "api",
          "url": "https://wavect.io/zh/glossary/api/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/saas/",
          "@type": "DefinedTerm",
          "alternateName": [],
          "description": "你租用而非拥有的软件：供应商托管它、运行它并收取订阅费，而客户只需通过浏览器登录。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "SaaS",
          "termCode": "saas",
          "url": "https://wavect.io/zh/glossary/saas/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/custom-software-development/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Custom Software Development",
            "定制开发",
            "软件定制"
          ],
          "description": "为单一组织的特定需求设计和构建软件，代码与知识产权归买方所有，而不是租用为普通客户打造的现成产品。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "定制软件开发",
          "termCode": "custom-software-development",
          "url": "https://wavect.io/zh/glossary/custom-software-development/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/software-agency/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Software Agency",
            "软件公司",
            "Software House",
            "软件服务提供商",
            "软件供应商",
            "软件开发合作伙伴"
          ],
          "description": "你雇来设计、构建并交付软件的公司。Software agency、软件服务提供商、dev shop、软件外包公司指的都是同一类公司，真正的差别在合作模式。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "软件开发公司",
          "termCode": "software-agency",
          "url": "https://wavect.io/zh/glossary/software-agency/"
        },
        {
          "@id": "https://wavect.io/zh/glossary/it-service-provider/",
          "@type": "DefinedTerm",
          "alternateName": [
            "Managed Service Provider",
            "MSP",
            "Systemhaus",
            "IT-Dienstleister",
            "托管 IT 服务商",
            "IT Service Provider"
          ],
          "description": "按 SLA 运维和支持你现有 IT 的公司：网络、设备、服务器、云、服务台。与软件开发公司不同，后者构建此前并不存在的软件。",
          "inDefinedTermSet": "https://wavect.io/zh/glossary/#termset",
          "name": "IT 服务提供商",
          "termCode": "it-service-provider",
          "url": "https://wavect.io/zh/glossary/it-service-provider/"
        }
      ],
      "inLanguage": "zh",
      "name": "Wavect 术语表",
      "url": "https://wavect.io/zh/glossary/"
    },
    {
      "@id": "https://wavect.io/zh/glossary/#webpage",
      "@type": [
        "WebPage",
        "CollectionPage"
      ],
      "about": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      },
      "author": {
        "@id": "https://wavect.io/team/kevin-riedl/#person",
        "@type": "Person",
        "name": "Kevin Riedl",
        "url": "https://wavect.io/team/kevin-riedl/"
      },
      "dateModified": "2026-05-24",
      "description": "我们在网站上提到的每一种角色、合作模式、技术与方法的定义。由真正做这份工作的运营者撰写，用一种创始人、CFO 或董事会成员当天就能直接使用的语言。",
      "headline": "Wavect 术语表",
      "inLanguage": "zh",
      "isPartOf": {
        "@id": "https://wavect.io/#website",
        "@type": "WebSite"
      },
      "lastReviewed": "2026-05-24",
      "mainEntity": {
        "@id": "https://wavect.io/zh/glossary/#termset"
      },
      "name": "Wavect 术语表",
      "reviewedBy": {
        "@id": "https://wavect.io/team/christof-jori/#person",
        "@type": "Person",
        "name": "Christof Jori",
        "url": "https://wavect.io/team/christof-jori/"
      },
      "speakable": {
        "@type": "SpeakableSpecification",
        "cssSelector": [
          ".gls-hero__headline",
          ".gls-hero__lead",
          ".gls-term__tldr"
        ]
      },
      "url": "https://wavect.io/zh/glossary/"
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        {
          "@type": "ListItem",
          "item": "https://wavect.io/zh/",
          "name": "首页",
          "position": 1
        },
        {
          "@type": "ListItem",
          "item": "https://wavect.io/zh/glossary/",
          "name": "技术、产品与合作模式术语表",
          "position": 2
        }
      ]
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "因为第一通电话里有一半的问题不是「你们能不能做」，而是「X 和 Y 有什么区别」。一份公开参考能为双方节省时间，也能让合同谈判更快推进。"
      },
      "name": "Wavect 为什么要发布术语表？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "每个词在 schema 里都带 `lastReviewed` 日期，并在深度页可见。我们至少每季度通读一次整份术语表，市场用法变化时即更新条目。"
      },
      "name": "更新到什么程度？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "可以。每个词条都有自己的深度页，例如 `/zh/glossary/ctpo/`。这就是用于链接或引用的规范 URL。"
      },
      "name": "可以单独链接某一个词吗？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不是。每条定义由 Kevin Riedl 撰写，Christof Jori 复核，我们其中之一对措辞有异议时再改。我们允许 LLM 索引这一页（这正是目的），但不让它来撰写。"
      },
      "name": "这是 AI 写的吗？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "接受。把缺失的词或你认为有误的定义发到 office@wavect.io。每一条我们都会看。"
      },
      "name": "你们接受建议吗？"
    }
  ],
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      ".faq-question",
      ".faq-answer"
    ]
  }
}
```