01自有服务能力 · 自研系统
ChefShot ABM 获客引擎
一个 SDR 一天手动跑 32 条线索。同一条管线按自己的 Worker 节拍跑 1,920 条——相当于 60 个 SDR，而你的成本只是 API 用量。
9 条已发布数字打开完整拆解
AI-Native Systems
WillChan 旗下的系统交付业务。
每天都在跑的系统。
瓶颈从来不是模型。是凌晨三点还在几个系统之间倒数据的那三个人，是没人敢信的报表，是只有一个人知道怎么走的流程。这里的每一套系统，都是因为其中某一项正在实打实地烧钱才被造出来的。
提交需求从 $200 起 —— 在任何投入之前，先做一次限定范围的排雷冲刺
适合谁
这适合谁，不适合谁。
- 你已经试过 AI，但没跑起来。买了没人打开的授权，做了个从没上过生产的 PoC。
- 有一个流程每天都在吃掉某个具体的人几个小时——而且你说得出那个人是谁。
- 预算和决策权都在你手上，而不是「我们哪天该看看 AI」。
- 你要的是交接过来的系统，不是租来的。你打算自己拥有并维护它。
这套服务不做什么
- 你需要一个拿去给董事会看的 demo。demo 不是系统，我们也不是做 demo 的。
- 范围必须保持开放。无边界的第一阶段，正是「两周的项目做成两个季度」的原因。
- 你需要的是工时表上的一个人，而不是一个确定的结果。
- 你希望我们先做出来，然后你再决定要不要付钱。
- 按人头按工时的外派。我按系统报价，因为按小时计费会让真正重要的决策在财务上对双方都不理性。
- 进入一个我无法影响流程的增员岗。如果架构已经定死、只允许我照着实现，那么找一位合约开发者是更便宜也更诚实的选择。
- 只交付页面而不交付系统。如果交付物是一组没人约定如何实现的视觉稿，那么无论稿子多好看，项目都会在交接处失败。
- 那些「你现在还不需要 AI」的项目。第一次通话我就会直说，而不是把模型卖给一个本该先把数据模型做清楚的流程。
作品
造出来就是为了不用有人在旁边盯着的系统。
排序依据是「哪一件最能让人坐直」，不是技术多炫。点进任何一件，每个数字背后的算式都写在旁边——你可以自己核，不用信。
这里的每一套系统都是自研的，跑在我们自己的环境里。它们不是客户案例，也没有任何外部组织在运行它们。这一点写在明面上，因为技术买家问的第一个问题就是「这是给谁做的」，而这个答案必须是真的。
能力槽
三个交付支柱。
- SLOT A
自主 AI 工作流
把大模型接入你既有的业务逻辑。从多智能体编排，到自建 MCP 服务部署。
交付物
- 架构简报：模型该出现在哪里，以及哪里绝不能交给它
- 自建 MCP 服务，把内部工具暴露给任何兼容的客户端
- 多智能体流水线：带类型约束的工具 schema 与确定性回退路径
- 上线前的评估夹具与回归集
- 按工作流与按席位计算的成本模型，含硬上限与熔断开关
- 可观测性：链路追踪、token 记账与失败重放
- SLOT B
设计工程
打通 Figma 到生产环境的断裂。交付像素级精确的 Next.js/React 前端，以及与之匹配的数据架构。
交付物
- 基于 Next.js App Router 的生产级实现，能静态渲染的一律静态渲染
- 把设计 token 写成带类型的代码，两套主题共用一个事实源
- 数据层：schema 设计、缓存策略，以及被设计过的加载／空／错误态
- 在 CI 里强制执行的 Core Web Vitals 预算，而不是写在文档里的愿望
- 在关键流程上达到 WCAG 2.2 AA
- 一套你的团队不需要问我就能扩展的组件库
- SLOT C
系统级交互架构
不再交付孤立的页面。为复杂的 B2B SaaS 产品构建可扩展的设计系统，以及 Liquid Glass 质感的界面体系。
交付物
- 围绕操作者的真实决策重建信息架构
- 信息密度策略：什么常驻可见，什么只差一次交互，什么永远不该出现
- 异步 AI 工作的交互模型：进度、部分结果、中断与撤销
- 面向多租户产品的角色化界面设计
- 治理机制：设计系统自身的命名、版本与废弃规则
- 书面的决策日志，让推理过程在人员更替后依然留存
服务方向
接下来能建什么。
这两项不是我们交付过的东西。它们是我们有能力去建的系统，而且刻意标成「方向」而不是「项目」：一个方向只有在真实跑过一遍、并留下可测量的数字之后，才有资格变成作品，在此之前不行。
- 服务方向 · 未交付
全域内容自动化衍生流水线
一次产出，自动衍生为 X / LinkedIn / Newsletter / 社媒多版本文案，推入发布队列，人工一键确认后发。
它替代的是什么
内容团队的时间被「改写成不同平台版本」吃光：同一篇长文要手动改 4 遍，改完还要逐个平台登录发布。断点发生在「写完」与「发出去」之间。
架构
Trigger：新长文 / Changelog 落地（RSS、Git 或手动投递）→ Brain：LLM 蒸馏出平台特定版本（长度、语气、hashtag、CTA 各一套），并做一次事实一致性校验 → Action：Webhook 推入发布队列，人工一键确认后发。
防护栏
- 事实一致性锁（设计）：衍生稿只允许从原稿抽取事实，禁止新增数字。这正是本站自己已在执行的纪律，所以它是我们在遵守的规则，而不是我们要强加给客户的规则。
- 平台长度硬校验（设计）：超限直接打回，不静默截断——截断的发文比缺失的发文更糟。
- 进队列 ≠ 已发布：队列与平台之间有人工闸门，不存在自动发布路径。
你会拿到
- 工作流蓝图：可导入你自己云环境的 n8n / Dify JSON。
- 平台模板库：每个渠道一套模板，带版本。
- 发布队列看板及其接口文档。
技术栈: n8n · Dify · LiteLLM · PostgreSQL / Supabase · Next.js
谁最需要 出海 D2C 品牌、SaaS 内容团队、独立开发者——一次生产、需要零边际成本分发的人。
- 服务方向 · 未交付
线索自动分析与提案预处理雷达
客户一提交需求，系统自动做完企业画像 → 匹配度打分 → 初版 SOW 预案，让你在 10 分钟内回一封像样的话。
它替代的是什么
高客单 B2B 的询盘回复质量取决于「销售当时有多空」。断点发生在「收到询盘」与「发出有内容的回复」之间——通常要 1–2 天，客户已经凉了。
架构
Trigger：本站的需求表单，或邮箱 / LinkedIn 询盘入口 → Brain：抓官网与公开信息做企业画像 → 按 ICP 规则打分 → 生成初版执行框架（含范围、假设与风险）→ Action：推送到 Slack / 飞书交互式卡片，人工 [Approve] 后回信。
防护栏
- AI 只起草，人发送。与外呼管线同一条红线：任何面向潜在客户的自动消息都不发。
- SOW 预案必须标出自己的假设：未确认的必须写「待确认」，不允许把未验证的猜测写成结论，否则猜测会硬化成承诺。
- 只用公开信息。企业画像来自公开来源，隐私与个人数据在设计上就不在范围内。
你会拿到
- 富化管线蓝图。
- ICP 打分规则表——改规则不用改代码。
- SOW 模板引擎与审批卡片流。
- CRM 回写映射。
技术栈: n8n · company data APIs · LLM extraction · Dify / Qdrant · Slack / Feishu cards
谁最需要 咨询公司、代理公司、高客单 SaaS、出海服务商——响应速度直接换转化率的地方。
一次合作怎么开始
一次合作怎么开始
按阶段固定范围交付，写代码前先交付一份架构简报。报价按系统而非按工时计算，因此范围蔓延是双方共同面对的问题，而不是一张隐藏的账单。
- 01
架构简报
写第一行代码之前的一页文档：瓶颈、能解锁它的那个决策、系统的形态，以及量级上的成本。即便合作到此为止，这份文档也归你。
- 02
固定范围构建阶段
两到十周，一份书面范围，每周都有可运行的软件。任何一个阶段结束时，都有东西跑在真实环境与真实数据上。
- 03
交接与运行闭环
决策日志、运行手册，以及一次录屏走查。之后只在系统确实需要持续调优时才进入顾问期，而不是默认续约。
常见问题
值得认真回答的几个问题。
- 你们和普通 AI 外包 / Agency 有什么区别？
- 你拿到的是一套可以交接的系统：工作流定义、Agent 的 Prompt 与输出 Schema、runbook，以及解释「为什么这么设计」的决策日志——不是一段 demo，也不是只有作者看得懂的仓库。第二个区别更难伪造：我们自己先给自己造工具，证据就在这一页上。一家从没运营过自己赖以生存的系统的外包公司，对你的系统只能是猜。
- 一个系统多久能上线？
- 排期口径是「2 周 / 一个系统一个垂直」——这是估算，不是实测。诚实的补充是：范围必须在开工前定死，因为无边界的第一阶段正是「两周项目变成两个季度项目」的原因。$200 的限定范围 sprint 存在的意义，就是在你承诺更大投入之前把范围钉住。
- 我们的流程很乱，能自动化吗？
- 有时不能——$200 sprint 就是为了便宜地发现这一点。它产出一份固定范围的架构简报，先指出失败路径：哪个集成撑不住、哪份数据其实不存在、哪个环节手工是为了一个没人记录下来的原因。自动化一个没人能描述的流程，只会得到一个更快版本的错误流程。如果诚实的答案是「这里不该上 AI」，简报就这么写。
- AI 会不会瞎编（幻觉）？
- 具体做法，这一块是工程而不是表态：结构化输出由 JSON Schema 强约束，格式不合法的回答根本无法被解析成动作；每条生成结果都带置信度分数，低于阈值直接进人工复核队列而不继续；带检索的 Agent 只从给定知识库作答，所以点评引用的是规则而不是意见；关键环节上管线停在人工 [Approve]，而不是自己判断着往下走。
- 交付后你们还管吗？
- 管，走 AI Systems Retainer，这是立场而不是加售。这类系统会腐坏：模型被弃用、API 改了限速、来源页面改了结构，一套六个月没人碰的工作流会在某个早上停掉。没有维护协议的的系统，就是一套有已知保质期的系统。这也是名字叫 Systems 而不是 Service 的原因——维护本身就是重点。
- 你们做过什么？
- 都是我们自研自跑的系统，每一套连架构带数字一起公开。最强的一条是日跑 1,920 条线索的外呼管线，人工基线是 32 条——约等于 60 个 SDR 的产能。最弱的一件是刻意的：一套苏格拉底式教学引擎，没有任何性能数字，因为它诚实的卖点是「怎么教」，不是「多快」。这个落差本身就是重点：能证明的我们公开，不能证明的我们直说。
- 为什么很多是「自研」而不是客户案例？
- 因为它属实，而且它比一面 logo 墙更有力。这些是我们给自己造、自己跑的系统；没有任何外部组织在运行它们，页面上每张卡都写明了这一点。这一点是可验证的，而客户 logo 不是——谁都可以声称服务过世界 500 强，但一条处理运营者自己线索的管线必须真的能跑，否则运营者自己就会发现。客户案例只在合同允许时才公开，也不存在任何一种情况下我们会暗示一个不存在的客户。
把需求写下来，拿到书面回复。
用表单把问题描述清楚。你收到的是一份针对你情况的书面回复——包括在「其实不该做」时，直说这件事。
提交需求如果你确实更想聊一次而不是写下来，预约页在这里。 预约策略通话