如何把一个技术题讲出业务价值
一句话先讲清楚
技术题如果只讲实现，很容易显得像在背知识点；真正更像成熟工程师的讲法，是把技术设计和业务价值连起来。
一个通用公式
我一般会按这个顺序讲：
-
先讲业务问题
为什么会需要这个技术方案。 -
再讲技术矛盾
到底卡在性能、稳定性、扩展性还是沟通成本。 -
再讲设计方案
你怎么拆层、怎么取舍。 -
最后讲业务价值
它减少了什么成本，提升了什么能力。
30 秒版本
很多技术题本身并不难，难的是你能不能讲清楚“为什么值得做”。比如讲监控 SDK，如果只讲怎么采错误和性能，它就是一个技术实现；但如果你能讲成“它帮助团队更快发现线上问题、量化体验、减少人工排查成本”，它的价值层次就完全不一样了。我的习惯是先讲业务问题，再讲技术设计，最后再落到效率、稳定性和协作成本这些业务结果上。
1 分钟版本
我觉得技术题最容易答偏的地方，就是一上来就进入实现细节，比如 API、类设计、目录结构。这样当然也能答，但会显得你只是会做，不一定知道为什么做。
所以我通常会先把技术题翻译成业务问题。比如监控 SDK 不是“我要采错误”，而是“团队需要更快发现线上问题并量化用户体验”；埋点 SDK 不是“我要发事件”，而是“团队需要稳定地理解用户行为和业务转化”；履约建模也不是“我要建一个模型”，而是“我需要先给 AI 和人建立稳定上下文，降低沟通成本”。
这样一来，后面的技术设计就有支点了。你讲分层、插件、采样、领域事件这些，不再是炫技，而是在解释你怎么解决一个真实问题。最后再补一句这个设计降低了什么成本、提升了什么效率，整道题就会完整很多。
2 到 3 分钟版本
我自己在面试里会刻意做一件事，就是把纯技术题讲成“技术设计服务于业务结果”的题。因为很多技术设计如果脱离业务语境，就很容易变成概念堆砌。
比如面试官问监控 SDK，如果我只回答
window.onerror、PerformanceObserver、sendBeacon，这些当然都对，但面试官听完以后，还是不知道你是不是一个只会写实现的人。更好的方式是，先把它翻译成业务问题。比如监控 SDK 的业务价值在于帮助团队更快发现问题、减少线上排查成本、量化真实用户体验；埋点 SDK 的业务价值在于让产品和业务团队能稳定理解用户行为，而不是每次改版都把历史数据打断；履约建模的业务价值在于让 AI 和人基于同一套上下文协作，降低沟通失真。
当你先把价值说清楚以后，后面的技术设计才会显得有必要。你为什么要做插件化？因为需求会继续扩，团队不能每次都重构。你为什么要做统一事件模型？因为后续的数据分析、治理和告警都依赖它。你为什么强调领域事件？因为 UI 会变，但业务语义要尽量稳定。
所以我通常会让回答形成一个闭环：先有业务问题，再有技术矛盾，然后是设计方案，最后落到业务结果。这样你讲的就不是“我会这个技术点”，而是“我知道这个技术点在真实团队里为什么重要”。
我觉得这也是高级一点的表达方式。因为团队不会因为你用了某个模式就买单，而是因为它真的降低了成本、提升了效率、提高了稳定性。
一个很实用的万能模板
这个问题我会先从业务价值看。因为团队当时遇到的是 X，所以单靠原始做法会有 Y 的问题。基于这个前提，我才采用了 Z 这套技术设计。这样做的直接好处是 A，长期价值是 B，代价是 C，但结合当时阶段，我觉得这个取舍是合理的。
适合套用的例子
监控 SDK
不是采错误，而是减少排障成本、量化体验。
埋点 SDK
不是发事件，而是沉淀稳定业务数据。
履约建模
不是建模，而是给 AI 和人建立共同上下文。
HATEOAS
不是追 REST 概念，而是降低前后端耦合和动作硬编码。
最后一句收尾
所以我现在讲技术题，都会尽量先讲“为什么值得做”，再讲“怎么做”。因为只有这样，技术方案才会显得像真实项目里的决策，而不是单独存在的知识点。
套用到项目中的版本：Routa.js 项目介绍
Routa.js 是一个面向软件交付场景的 workspace-first 多智能体协同平台。它不是单纯的 AI Chat 工具，也不是偏通用内容生成的 AI 应用编排平台，而是把真实研发流程中的 Workspace、Task、Session、Codebase、Worktree、Trace、Review、Artifact 等对象显式建模，再通过 Kanban 与 Specialist Agent 把需求澄清、任务拆解、开发实现、评审放行、完成归档串成一个可观测、可治理的闭环。
项目提供 Web、Desktop、CLI 三种产品形态。Web 端基于 Next.js 16 与 React 19；Desktop 端基于 Tauri 与 Rust/Axum，强调本地优先、SQLite、本地 Agent Runtime、Docker Sandbox 和本地文件系统能力；CLI 端则适合终端优先和脚本自动化场景。三者不是三套独立产品，而是共享同一套领域语义和 API 契约，并通过 api-contract.yaml 保证一致性。
在能力层面，Routa 的核心不是让一个 Agent 会写代码，而是让多个 Agent 在工程约束下协同交付。平台支持工作区级任务与看板协同、代码仓库与 Worktree 管理、GitHub 仓库导入、会话流式执行、Trace 追踪、Review 分析、Workflow、Schedule、Webhook、Background Task 自动化，以及 ACP、MCP、A2A、AG-UI、A2UI、REST、SSE 等多协议接入。
在架构上，项目采用双后端语义一致设计。Web 侧由 TypeScript 的 RoutaSystem 统一装配领域服务，Desktop 侧由 Rust 的 AppState 统一装配本地运行时能力。底层存储和进程管理可以不同，但上层的工作区、任务、会话、审查、追踪等产品语义保持一致。为了避免 AI 在复杂仓库里无约束地乱写，项目还构建了 Trace、Review、Entrix Fitness、Harness Monitor 的治理闭环，用可执行证据、硬门禁、契约校验和运行观测来约束交付质量。
如果压缩成一句简历表述，可以这样说：设计并开发了一个面向软件交付的企业级多智能体协同平台，基于 Next.js、Tauri、Rust/Axum 构建 Web、Desktop、CLI 三端统一架构，通过 ACP 归一化多 Agent Runtime，以 Workspace、Kanban、Trace、Review、Fitness 建立可观测、可治理的 AI 交付闭环。
对应面试问题的完整口述稿
- 如何设计一个支持多智能体协作的软件交付平台
这个问题我一般会从领域建模、协作编排、运行时抽象、治理闭环四层来回答。首先我不会把它理解成把多个机器人放到一个聊天框里，因为真实的软件交付不是围绕单次对话展开的，而是围绕工作区、代码仓库、任务、执行过程和验收证据展开的。所以在 Routa 里，我先把 Workspace 设计成顶层边界，再把 Task、Session、Codebase、Worktree、Note、Artifact、Trace 这些对象做成一等公民，让系统的状态不再隐含在聊天记录里。
第二层是协作编排。我没有让所有 Agent 共用一个模糊的大 Prompt，而是用 Kanban 列去承载不同阶段的职责，比如 Backlog 负责需求澄清，Todo 负责把需求变成可执行计划，Dev 负责落地实现，Review 负责独立验收，Done 负责归档总结。这样每一列都是一个明确的协作边界，每次流转都意味着责任切换、证据增加和信任收紧。
第三层是运行时抽象。不同 Agent Provider、不同 CLI、不同执行环境都不应该直接污染业务层，所以我会在下面抽象统一的执行协议和状态模型。Routa 里用 ACP 作为主执行协议，把 Provider 的差异封装到 Adapter 层，统一再往上暴露会话更新、消息流、工具调用、Trace 和 UI 事件。
最后一层是治理闭环。多智能体系统如果只有执行，没有审查，很快会失控。所以我给它配了 Trace、Review、Fitness、Harness 这几层，分别解决发生了什么、是否满足验收标准、是否通过工程门禁、仓库是否适合高自治 Agent 运行这几个问题。我的核心思路是，多智能体平台的本质不是聊天增强，而是把软件交付流程工程化、对象化和可验证化。
- 如何保证 Web、Desktop、CLI 三个入口的一致性
我在设计时有一个很明确的原则，就是不能把 Web、Desktop、CLI 做成三套各说各话的产品。Routa 的做法是先统一领域语义，再统一 API 契约，最后才分别实现不同入口。也就是说，先定义什么是 Workspace、什么是 Task、什么是 Session、什么是 Trace，这些概念在三个入口里必须完全一致。然后再用 api-contract.yaml 作为契约源，约束 Web 和 Desktop 暴露出来的接口保持一致，CLI 也尽量复用同一套语义和能力模型。
具体实现上，Web 侧由 TypeScript 的 RoutaSystem 负责装配，Desktop 侧由 Rust 的 AppState 负责装配。它们底层可以分别接 Postgres、SQLite、文件系统、本地进程、Docker，但对上层暴露出来的仍然是同一套产品对象和行为。CLI 不是额外的一套后端，而是第三个使用入口，适合终端用户和自动化脚本直接调用这些能力。
为了防止三端逐渐漂移，我会再加两层约束。第一层是契约校验，比如 API parity 检查，确保接口层不偏。第二层是 Fitness 和测试，把 lint、类型、单测、API 测试和质量规则变成硬门禁。这样三端不是靠大家自觉保持一致，而是靠契约和验证机制去持续收敛。
- 为什么 Kanban 不只是一个 UI，而是系统中的核心编排边界
这个问题我会直接说，Routa 里的 Kanban 不是把任务状态画成几列，而是把交付流程显式建模成一组受约束的协作阶段。很多系统里的看板只是展示层，真正的逻辑还藏在聊天、脚本或者人工操作里。但在 Routa 里，列迁移本身就是领域事件，它可以触发 ACP 会话、触发队列并发控制、触发审查规则，也会改变下一阶段允许信任什么信息。
举个例子，任务在 Backlog 列时，重点是把模糊需求整理成结构化故事；到了 Todo 列，就必须补齐执行计划、关键文件、风险和依赖；到了 Dev 列，才允许真正编码，并且要产出验证证据；到了 Review 列，又会从实现者视角切换到验收者视角，独立检查 acceptance criteria、测试结果和 git 状态。所以同一张卡片在不同列其实代表不同的业务语义，而不是单纯的颜色变化。
这么设计的好处是，协作链路会非常清晰。谁负责什么、什么时候可以交接、什么时候必须拒绝放行，全部可以通过列策略表达出来。这样系统不会退化成多个 Agent 围着同一条消息各说各话，而是真正形成有边界、有节奏、有证据的交付流水线。
- 如何统一不同 Agent Provider 和运行时的行为差异
我的核心思路是不要让 Provider 差异直接泄露到业务层。因为不同 Agent 运行时的差异非常大，有的原生支持 ACP，有的是自定义流式输出，有的是 CLI 进程，有的是 Docker 容器，如果业务层直接感知这些差异，系统很快就会变得不可维护。所以 Routa 采用的是协议归一化方案，把 ACP 作为主执行协议，再在下面增加 Provider Adapter。
具体来说，底层流程是这样的：Provider 进程先产出自己的原始输出和通知，然后由 Adapter 把这些内容转换成统一的会话更新模型，再进入持久化、Trace、SSE 推送和 UI 刷新链路。这样上层看到的始终是统一的 Session 生命周期、统一的消息事件、统一的工具调用和错误状态，而不是某个 Provider 的私有格式。
这个设计的价值有两个。第一，平台更容易扩展，新接一个 Provider 时主要改 Adapter，不需要重写整个产品。第二，治理能力更容易统一，因为 Trace、Review、Streaming、权限控制这些都可以建立在归一化之后的模型上，而不是分别适配每个 Provider。换句话说，Provider 是可插拔的，平台语义必须是稳定的。
- 你们是怎么做 AI 时代的软件交付治理的
我会说，这个项目最重要的其实不是让 Agent 能执行，而是让 Agent 的执行可追踪、可审查、可拦截。因为一旦进入真实工程环境，AI 最大的问题不是不会写，而是写了以后没人知道它为什么这么写、改了什么、有没有破坏约束。所以 Routa 做的是分层治理。
第一层是 Trace，它回答到底发生了什么，包括会话生命周期、消息历史、工具调用、文件变更、Git 上下文。第二层是 Review，它回答这次改动是不是满足验收标准，而不是只看表面代码风格。第三层是 Entrix Fitness，它回答从工程门禁角度，这个结果是否允许放行，比如 lint、typecheck、测试、API 契约、一致性、安全规则等。第四层是 Harness Monitor 和 Fluency，它回答当前仓库是否适合高自治 Agent 继续工作，更偏平台治理和仓库成熟度评估。
这四层叠起来以后，系统就不是一个 Reviewer Agent 给点意见这么简单了，而是形成了从事实记录、质量检查到放行决策的完整闭环。我在设计上比较强调一点：AI 交付治理不能靠主观感觉，必须尽量落到可执行证据和结构化规则上，否则规模一大就一定会失控。
- 如何实现本地优先和私有化部署
这个问题我通常会从产品形态和运行时能力两个维度回答。产品形态上，Routa 同时提供 Web 和 Desktop。Web 适合团队自托管和浏览器访问，Desktop 适合本地优先、数据敏感和开发者日常使用。运行时能力上，Desktop 不是一个简单的壳，而是内嵌了 Rust 和 Axum 本地服务，默认走 SQLite、本地文件系统、本地 Agent Binary、Worktree 和 Docker Sandbox，所以很多能力可以在用户机器本地完成。
这样做的好处是，涉及仓库扫描、本地代码执行、文件操作、运行时安装这些天然偏本地的能力，不需要强行绕远路走远端服务。对于很多企业场景，这一点很重要，因为他们既要用 AI，又不希望把代码和运行过程完全托管出去。另一方面，如果企业有统一部署需求，也可以走 Web 模式，用 Next.js 加数据库服务来承载团队协作和集中访问。
但我要强调一点，本地优先不等于做两套系统。真正难的是底层资源模型不同，但上层语义不变。Routa 的做法就是让 Desktop 和 Web 在持久化和运行时能力上各自发挥优势，但在 Workspace、Task、Session、Trace、Review 这些核心概念上保持一致，这样用户切换入口时不会感觉自己在用两个不同产品。
- 你们的 CLI 在整体架构里是什么定位
CLI 在这个项目里不是附属品，而是第三个正式入口。很多开发者并不想一直开着 Web 或 Desktop，他们更希望在终端里直接对仓库发起一次分析、查看 workspace、调用 ACP runtime，或者跑 fitness fluency 这类治理命令。所以 routa-cli 的价值是把平台能力带到 terminal-first 场景和自动化脚本场景里。
从架构上说，CLI 也不应该变成一套独立逻辑。它应该尽量复用同一套领域语义和运行时能力，只是交互方式不同。这样用户在 Web、Desktop、CLI 三端切换时，学的是同一套产品模型，而不是三套命令体系。对企业来说，这也很重要，因为 CLI 更容易接 CI/CD、脚本任务和本地工具链，能把平台从人手点点点扩展到可自动化执行。