Wavect 术语表

CTPO 同时承担 CTO 与 CPO 的职责。他负责要造什么、怎么造，以及最终是否真正解决客户问题。这个角色存在的原因是：PMF 之前的初创公司既无力承担两个高级聘用，也无力承受 CTO 与 CPO 每个星期二为优先级争吵的政治成本。

在 Wavect 的项目中，CTPO 多数是 fractional 的。一位运营者进入股权或合同关系，在同一周里同时跑产品发现与技术架构，等公司有了营收与组织规模能支撑两人时，再交接给永久的拆分（CTO + CPO）。

风险是：一个人变成单点故障。缓解方法是：CTPO 自己知道什么时候该停止做 CTPO 并去招到自己的继任者。不愿意自己「下岗」的，就不是合适的 CTPO。

CTO 拥有三件事：你在什么之上构建、交付得有多稳定，以及两年前选的架构今天是否还服务于业务。他不只是最资深的工程师。他是决定哪些火该灭、哪些火该明确承认并搁置的运营者。

在 Wavect 我们区分三种形态。Founding CTO 在股权表上，且亲自写代码。Scale-up CTO 下面有 20+ 工程师，主要做工程管理。Fractional CTO 用于填补：营收还不足以支撑前两种全职角色时的过渡。

最常见的错误：在公司需要 Founding 形态时却请了一位 Scale-up CTO。简历漂亮，资金在半年内蒸发。把人选与阶段匹配清楚。

CPO 负责产品本身。不是设计、不是工程、不是营销，而是「要把什么、按什么顺序送到客户面前」这个问题。这个角色存在的原因是：每一次发布决定，同时也是一次不发布另一件事的决定，规模一大，就需要有人来对此负责。

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

在 PMF 之前，专职 CPO 通常过度配置。这一职责会被创始人或 CTPO 吸收，直到工程团队规模大到需要专人全职思考「下一个该做什么」。

Fractional Co-Founder 是 Wavect 的旗舰服务，名副其实。我们以联合创始人的状态嵌入：产品策略、技术架构、Sprint 计划、客户对话、董事会准备。我们不带工时表登场，我们带结果登场。

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

我们不适合所有人。如果你需要的是「干活的人」，请去找外包。如果你需要一个会挑战你路线图、周日晚上 11 点和你一起咬牙做架构决定、并在你最爱的功能其实是错的时候直接告诉你的人，这就是你要的合作形态。

Fractional CTO 这个市场存在，是因为太早请全职 CTO 太贵，太晚请又会致命。Fractional CTO 弥补中间这段：做架构决定、推进资深工程师的招聘流程、出席董事会、撰写投资者材料里的技术部分。

他通常不写生产代码。如果团队需要的是一个强独立贡献者，那你要的是一位资深工程师加上一位 CTO 作为思考伙伴，而不是 Fractional CTO 自己亲自写工程。在 Wavect 团队小到 CTO 也必须发布时，我们偶尔会模糊这条线，但会在 SoW 里把界线写清楚。

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

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

适用面较窄：公司需要产品上的资深度，但还撑不起全职 CPO，并且创始人愿意把产品判断权交出来。如果创始人本身就是产品的人，并且不愿意分享这份权力，Fractional CPO 只会带来摩擦。

Tech Lead 首先是独立贡献者，其次才是协调者。写代码、Review 代码；两位工程师对实现意见不一致时拍板。但他不是经理：不处理晋升、绩效评估，也不负责团队之外的招聘。

在 Wavect，我们常把 Tech Lead 与 Fractional CTO 一起部署。CTO 负责架构与跨团队协调。Tech Lead 负责本团队日常产出的质量。把这两个角色混为一谈，是我们在 A 轮初创公司里最常见到的错误。

工程经理管的是人，不是架构。他们在工程师与公司其余部分之间：把策略翻译成团队层级的优先级，主导招聘流程，承担没有工程师愿意主动开的对话。

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

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

在奥地利与德国法律下，对应的工具是 Werkvertrag，它比英语 SoW 更强：供应商在法律上必须交付成果，而不仅仅提供劳动。在同一法律框架下，按时间和材料计费的合同叫 Dienstvertrag，只承担劳动义务。Wavect 的固定价格合作都是 Werkvertrag。

SoW 同时也是防止范围蔓延的文件。任何不在 SoW 里的内容，按定义就在范围之外，需要通过 Change Request 处理。这不是法律繁文缛节，这是双方在六个月后不吵架的前提下，唯一能就「做完了」达成共识的方式。

Time & Material 是 Staffing Agency 与多数 Freelance 合同的默认模式。你按小时或按天付费；供应商记录工时；账单按月来。合同里没有「成果」这件东西，只有「投入」。

这种模式在「没人假装供应商对结果负责」这一点上是诚实的。但在常见模式中它的激励对齐也最差：供应商的动机是多记工时，而不是更快做完。聪明的客户会给 T&M 加上预算上限和清晰范围，本质上是把 SoW 重新发明一遍，但少了法律约束。

Wavect 在范围真的无法事先定义的探索性项目里才用 T&M。我们不把它作为默认。如果有人把明确交付物的工作往 T&M 上推，那就是在把风险塞给你。

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

要让这一切是真的而不是表演，合同必须是 Werkvertrag（奥/德法律下）或当地最接近的等价物。「固定价格」只是口头承诺、底层却是 T&M，那不是固定价格，那是一句营销话术。

Wavect 在范围已经清楚、且发现工作已经做过的项目上使用固定价格。在「发现之前」的项目上，我们先做 2 至 3 周的 Discovery Phase，本身也按固定价格收费。如果你之后继续与我们做 Build，发现阶段的费用会从首张发票里扣除。

Wavect 的固定价格保证意思是：签署过的 SoW（Werkvertrag），法律上必须交付。它不等于「错过截止日期就退款」。

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

当工作是持续的，且优先级变化太快、SoW 跟不上时，Retainer 适合。产品团队用 Retainer 找设计合作伙伴，工程团队用它聘 Fractional 资深角色，绝大多数法律顾问也都是 Retainer 形式。

风险与 T&M 相反：没有活的时候供应商也照拿钱。聪明的客户会加上「合理使用」条款，每季度复盘 Retainer。利用率低于 60%，说明形式不对，应改为按项目的 SoW。

Discovery 是「能诚实报出固定价格 Build」之前必须完成的工作。它产出四个文档：软件架构、里程碑计划、关键技术流程图与上线计划。基于这些，供应商才能给出真正的固定价格。

Wavect 把 Discovery 作为 2 至 3 周、3,500 欧元的固定价格项目运行。如果你随后与我们继续做 Build，Discovery 的费用会从第一张发票里扣除；如果不继续，你也保留这四份产出，可以拿给其他供应商。

为什么 Discovery 要收费：免费做范围评估，要么不诚实（供应商在 Build 报价里把成本拿回来），要么质量低（供应商赶工，因为反正没人付钱）。收费修正了激励。

Sprint 原本是 Scrum 里的术语，后来扩散到日常用语，泛指任何短时盒式工作单元。原始定义有三件事：固定长度、开头的计划会议、结尾的复盘。多数团队保留前两个，去掉了第三个，所以很多团队把节奏叫「Sprint」，但拿不出可演示的增量。

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

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

在实践中，这覆盖钱包、智能合约、去中心化交易所、NFT、DAO、Account Abstraction、ZK 系统、跨链桥及其上的应用层。Wavect 在 EVM（Ethereum 及兼容链）、Solana、Cosmos、Polkadot、Near、Ton 与 ICP 上构建。

诚实版本：多数 Web3 项目并不需要区块链。真正需要的（资产必须在供应商破产后仍然存在；无中心运营者的多方信任；无许可的可组合性）有价值；其余多是 VC 资助的分心项。我们会告诉你你属于哪一类。

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

在生产中 ZK 有两类常见形态。ZK-SNARK 体积更小、验证更快，但需要 Trusted Setup。ZK-STARK 更大也更慢，但不需要 Trusted Setup 且抗量子。多数链已经为常见证明（身份、余额、投票资格）提供了预制电路，因此不必专门聘密码学家。

商业价值范围比炒作的窄：当你需要在链上（或对一个交易对手）证明某个属性而不泄露数据时，ZK 真的有用。多数消费级应用用它属于杀鸡用牛刀。

在标准 EVM 链上，每个账户要么是外部拥有账户（一对私钥），要么是智能合约。ERC-4337 引入了第三类：用户用一个智能合约账户来进行交易。因为账户本身就是合约，里面可以包含逻辑。这些逻辑可以替用户付 Gas、通过 Guardian 恢复丢失的密钥、把多个调用打包进一笔交易、或强制执行像日支出上限这样的鉴权规则。

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

Wavect 已经把账户抽象钱包以及 MetaMask Snap 推到生产环境。这项技术是真实的，并且越来越主流。但实现并不简单。如果一家供应商把 AA 当作便宜的附加项报价，请问清楚他们用的是哪一套基础设施、合约代码经过了哪些安全审计。

AI Agent 是这套循环，不是模型本身。模型（Claude、GPT、Gemini、开源权重 LLM）负责决策。Agent 是运行时：给模型一个目标，允许它调用工具（数据库、API、代码解释器、另一个 Agent），观察结果，把结果喂回循环，直到完成。

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

Wavect 的立场：先问「AI 是不是这里合适的工具」，再问「Agent 是不是合适的 AI 形态」。多数被包装成「Agentic」的工作流，用「确定性流水线 + 中间一次 LLM 调用」其实更好。

Model Context Protocol（MCP）之于 AI Agent，相当于 HTTP 之于 Web：一份共享、开放的标准，规定模型如何与外界对话。Anthropic 在 2024 年末推出，2025 与 2026 年被广泛采用。

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

对企业来说，实际意义是杠杆。把内部工具、数据库与 API 封装成 MCP 服务器后，它们就能被本季度团队选用的任何 LLM 调用，更换模型时无须重写。代价是 MCP 还年轻：工具链、安全模型与审计模式还在成熟。我们经常构建 MCP 服务器并已经部署到生产；与此同时，每一次我们都会写一份安全评估，因为标准还在变。

RAG 是让 LLM 能回答它没被训练过的数据相关问题的架构。机制很直接：拿用户的问题，从你的语料里检索最相关的片段（向量检索、关键字检索或两者混合），塞进 Prompt，让模型回答。

RAG 之所以存在：用私有数据训练模型既贵又慢，而且数据一变就过时。RAG 用「把数据当作运行时上下文」绕过了这一点。代价是检索质量成为瓶颈；上下文差的模型会信心十足地答错。

关于 RAG 的不性感真相：80% 的工作是把检索做好（切块策略、Embedding 选择、Rerank、混合搜索），20% 才是模型本身。把 RAG 包装成一键式功能的供应商，卖的是容易的那一部分。

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

多数生产级智能合约系统不是单一合约，而是一组：Proxy 实现可升级，Implementation 承载逻辑，Access-Control 合约承载治理。这种模式对做过 API 版本化的人来说并不陌生，但出错的代价更高。

Wavect 用 Solidity 写 EVM 链上的合约，用 Rust 写 Solana、Near、ICP 上的合约。对于任何持有非琐碎资产的合约，我们建议在上主网之前请第三方做审计。我们已经把审计过的合约部署到生产；审计成本通常占 Build 预算的 1 至 2 周。

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

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

注意：EVM 兼容不等于 Ethereum 等价。Gas 定价、Precompile、共识行为上的细微差别，常常让没做逐链回归测试的团队踩坑。

Solana 与 EVM 不兼容。智能合约（在 Solana 里叫「Program」）用 Rust 编写，部署为 BPF 字节码，由 Solana 运行时执行。架构在吞吐（每秒数千 TPS）与低费上做了优化，代价是验证节点对硬件要求更高、去中心化分布与 EVM 链不同（也有人认为更中心化）。

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

Wavect 在 Solana 与 EVM 上都做交付。我们没有「链」偏好，只有「用例」偏好。

LoRaWAN 是让大规模 IoT 在经济上可行的网络层。设备用纽扣电池能跑数年，传输的载荷很小（几百字节），却能覆盖到数公里外的网关。代价：带宽很低、更新不频繁，以及不算简单的网关覆盖部署阶段。

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

LoRaWAN 适合「需要在很大范围内部署许多传感器、电池要撑数年」的场景。它不适合「需要高带宽、低延迟或每设备的蜂窝套餐」（后两者用 5G NB-IoT 通常更合适）。

Agile 比多数人以为的更老（《敏捷宣言》发表于 2001 年），落地得也比多数团队愿意承认的更糟。它最初的想法很简单：超过你能预测范围的计划，是浪费工作；所以短计划、发布、学习、再计划。其他一切（Scrum、Kanban、SAFe、Sprint、Retro、Story Point）都是在这之上的实施细节。

对一支宣称「我们在做 Agile」的团队最有用的问题是：上一次根据上周交付的结果调整计划，是什么时候？答案是「没有」，那这支团队就是在用两周块的瀑布。

Wavect 在原始意义上是 Agile 的：短循环、频繁演示，愿意把事后证明是错误的工作扔掉。我们对「认证产业版」的 Agile 抱怀疑态度，那种把会议节奏本身当目标的做法。

TDD 是一种纪律，不是方法论。循环是：红（写一个会失败的测试）、绿（写让它通过的最简代码）、Refactor（在不破坏测试的前提下清理）。严格执行能产生高测试覆盖率，以及一种「反过度工程」的强制力。

多数团队嘴上做 TDD、实际并不做的原因：当下感觉更慢。它的复利收益（Refactor 安全、回归保护、推动更小单元的设计压力）要数月之后才显现。等到那时，团队早就停止「先写测试」，并说服自己「反正没什么不同」。

Wavect 在合适的地方用 TDD：与「钱」相关的集成测试、面向客户的契约测试、复杂逻辑的单元测试。我们不为 Getter / Setter 写测试。把「覆盖率」当目标的指标，是用来被绕过的。

BDD 是把 TDD 的测试语言改写成非工程师也能读的形式。Cucumber 之类工具用 Given/When/Then 格式，让产品经理也能签字。意图是把测试与「它验证的业务行为」对齐，而不是与「当前的实现」对齐。

实际中，它在集成测试与验收测试层级价值最高，因为那层正是工程与产品之间语言屏障真正产生 Bug 的地方。在单元测试层级，BDD 引入的仪式比节省的多。

MVP 里 Viable 这个词承担了几乎全部的重量，而几乎所有人都理解错了。Viable 不是「最终产品的精简版」。Viable 是「足以验证这个产品是否值得继续做的假设」。带 Waitlist 的落地页可以是 MVP。带三个功能的可运行产品可能是比落地页更糟的 MVP。

最常见的失败：去做你六个月前想象中的那个 MVP，而不是去做能验证「本周最不确定的那个假设」的 MVP。每一周「应该验证的假设」都在变。多数 MVP 在发布前就已经过时。

Wavect 的 Discovery 阶段一部分就是用来修复这件事。在划定 MVP 范围之前，我们先命名它要验证的假设。如果假设是「用户想要功能 X」，那 MVP 就不是一个被打磨光滑的功能 X，而是「最便宜的方式去找出答案」。

PMF 出了名地难定义又出了名地好识别。Marc Andreessen 的启发式仍然有效：当用户、媒体与股东同时在拉你，你的问题不再是「找不到客户」而是「跟不上客户」时，你就知道你有 PMF 了。

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

为什么这关系到工程决定：PMF 之前过度为规模做工程的团队，是在烧 Runway。PMF 之后做得不够的团队，会被自己的成功吃掉。Wavect 在这条线两侧做不同的合作：PMF 之前用能让你学到东西的最便宜版本；PMF 之后加固、补文档、让你晚上能睡着。

SDLC 是把软件从「想法」到「退役」要经过的阶段归在同一个名字下的统称。不同方法论（瀑布、Agile、DevOps、Continuous Delivery）定义不同的阶段边界与不同的过渡方式，但阶段本身大致不变。

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

Wavect 偏好的形态：发现放在前面，设计与构建在短循环里穿插，自动化测试与部署从第一天就到位，运维有清晰的归属，退役有书面化的迁移路径。

Continuous Integration 意味着团队代码在每次变更时合并并构建，而不是等到最后做一次大爆炸式集成。Continuous Delivery 意味着每一次成功的构建都距离生产只差一次点击。Continuous Deployment 则把那次点击也省掉：每个通过测试的构建自动上线。

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

Wavect 每个项目在第一天就配好 CI。是否启用 CD 取决于这个项目的测试覆盖与运维纪律是否足以让自动发布安全。我们会直接告诉你属于哪一种。

Continuous Delivery 是 Continuous Deployment 的负责任版本。每一次变更都走相同的自动化构建、测试与发布准备流水线，最终产物是可发布的；但「是否真的发布」仍由人来决定。

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