Wavect 术语表

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

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

在 Wavect 的项目中，CTPO 多数是 fractional 的，通过我们的 Fractional Co-Founder 模式交付。一位运营者进入股权或合同关系，在同一周里同时跑产品发现与技术架构，等公司有了营收与组织结构能支撑两人时，再交接给永久的拆分（CTO + CPO）。在奥地利，这种合作通常是 freier Dienstvertrag，因为交付的是持续的判断，而不是一个固定的成果物。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

与 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 奥地利。

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

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

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

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

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

相关：Fractional CTO 奥地利。

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

在 Wavect，我们常把 Tech Lead 与一位 fractional CTO 一起部署。CTO 负责架构与跨团队协调。Tech Lead 负责本团队日常产出的质量：代码评审标准、团队如何实践 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 奥地利。

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

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

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

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

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

相关：Fractional CTO 奥地利。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相关：Fractional CTO 奥地利 公开了每个档位的固定价格。

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

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

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

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

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

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

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

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

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

相关：Fractional CTO 奥地利 把 Discovery 列为四个价格档位之一。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

当存在真正值得在投入构建之前消除的技术风险时，Wavect 才做 PoC。大多数项目并不需要它；它们需要的是一个为工作划定范围的发现阶段。我们会告诉你你面对的是哪一种。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EVM 是 Ethereum 发明、后来成为智能合约链事实标准的执行层。一个编译成 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。这个决定是安全对成本的取舍，而不是这个季度哪条链营销嗓门最大。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Layer 2 是一条从 Layer 1（通常是以太坊）借用安全性的区块链，而不是从头运行自己的共识。L2 在基础链之外执行交易，将它们打包，并把结果回传到 L1。大多数 L2 都是 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 的提款如何运作、终局性延迟有多长、以及由谁运行排序器。我们的区块链工作涵盖 L2 选型与部署。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BDD 是把 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 里的一个阶段，是为一个真实的沟通问题准备的工具，而不是一个为自身而采纳的流程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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