1. 这不是又一个“三步搞定App”的速成课：WorkBuddy 真实落地的六个阶段拆解
WorkBuddy 不是 IDE，不是低代码平台，更不是某个被包装成“AI编程助手”的营销话术。它是一个以开发者工作流为原点设计的、可插拔的智能协作环境——核心价值不在于写代码快，而在于让“从想法到上线”这条链路里，那些反复踩坑、重复造轮、沟通错位、环境不一致的隐形成本，被系统性地识别、拦截和自动化。我用 WorkBuddy 搭建过三个真实交付的 App：一个面向高校实验室的设备预约系统（Web + PWA）、一个跨境小众手作商的库存与订单管理后台（React Native）、还有一个给本地社区老人用的用药提醒小程序（Taro）。它们都上了线，但过程远非“一键部署”那么简单。标题里说的“六个阶段、十六个坑”，是我把每个项目从零开始到用户能打开使用的完整生命周期，像剥洋葱一样一层层拆开后，发现的真实断点。这些阶段不是线性的瀑布模型，而是螺旋式迭代中不断回溯、验证、重构的节点。比如，“本地能跑”和“线上可用”之间隔着至少五个技术鸿沟；“功能做完”和“用户愿意用”之间，藏着十几个体验细节的生死线。WorkBuddy 在这里扮演的角色，不是替代你思考，而是把你从“查文档、配环境、等构建、看日志、猜错误”的循环里解放出来，把注意力真正聚焦在“这个按钮点击后，用户下一步会做什么”这种本质问题上。它不承诺让你少写一行代码，但它能确保你写的每一行，都在为最终上线的那个版本服务。如果你正卡在“本地开发很顺，一打包就报错”、“测试环境没问题，生产环境白屏”、“UI 设计稿和最终效果差了一截”这类问题里，这篇复盘就是为你写的。它不讲概念，只讲我在 Mac、Windows、Linux 三套环境里，用 WorkBuddy 搭建、调试、发布 App 时，亲手填平的那十六个坑。
2. 六个阶段：从“灵光一闪”到“用户打开即用”的真实路径
2.1 阶段一：环境奠基——不是装软件，而是定义你的“可信执行域”
很多人以为 WorkBuddy 的第一步是下载安装包，点开应用。错了。第一步，是定义你的“可信执行域”。这听起来很抽象，但实际操作非常具体：你需要明确回答三个问题——这个 App 的目标平台是什么（iOS/Android/Web/PWA）？它的核心依赖有哪些（比如是否必须用到 WebAssembly、是否强依赖某个特定版本的 Node.js 或 Python）？它的敏感数据边界在哪里（比如 API 密钥、数据库连接字符串，哪些能进 Git，哪些必须隔离）？WorkBuddy 的workspace并不是一个简单的文件夹，而是一个声明式的环境契约。我见过太多团队，在初期随意创建 workspace，结果后期因为 iOS 构建需要 Xcode 14，而 Android 构建需要 JDK 17，导致 CI 流水线频繁失败。正确的做法是，在workbuddy init后，立刻编辑.workbuddy/config.yaml：
platforms: - ios: "16.0" - android: "33" - web: "es2022" dependencies: node: "18.17.0" python: "3.11.5" rust: "1.72.0" # 如果用到 Tauri secrets: - "API_KEY" - "DB_URL" - "JWT_SECRET"这个配置文件，就是你的“环境宪法”。WorkBuddy 会据此自动拉取匹配的 Docker 镜像，或在宿主机上安装精确版本的工具链。它甚至能检测到你本地已有的 Xcode 版本，并提示：“检测到 Xcode 15.2，但项目要求 16.0，建议使用 sandbox 模式隔离”。这不是炫技，而是把“环境不一致”这个万恶之源，从源头掐死。我那个设备预约系统，就是因为初期没做这一步，导致设计师在 macOS 上看到的字体渲染和 QA 在 Windows 上看到的完全不同，最后花了两天时间才定位到是 Chromium 内核版本差异导致的 CSS 变量解析 bug。WorkBuddy 的 sandbox 模式，本质上是给你一个“可控的、可重现的、可审计的”开发沙盒，而不是一个随心所欲的游乐场。
2.2 阶段二：技能装配——WorkBuddy 的 Skill 不是插件，是你的“领域知识代理”
WorkBuddy 的 Skill 库常被误解为 VS Code 插件的翻版。这是最大的认知偏差。一个 Skill 的本质，是你把某个垂直领域的“最佳实践”封装成一个可复用、可组合、可审计的原子单元。比如skill-react-native，它不只是帮你生成一个App.js文件，而是内置了：
- 针对不同 React Native 版本（0.71 vs 0.73）的桥接层适配逻辑；
- 对
react-native-screens和react-navigation的版本兼容性矩阵； - 一套预设的 ESLint 规则，强制
useMemo和useCallback的使用场景； - 一个
wb run test:ios命令，它背后调用的是xcrun simctl boot启动模拟器，再执行jest，最后自动生成覆盖率报告。
我搭库存管理后台时，直接用了skill-react-native@v2.4.0。它帮我避开了 RN 0.72 中一个著名的AsyncStorage在 iOS 17 上的崩溃 bug——这个 bug 官方文档里没提，Stack Overflow 上的解决方案五花八门，而 Skill 的维护者已经把它作为一个已知问题，在prebuild钩子里自动注入了补丁。这就是“领域知识代理”的价值：它把散落在全球开发者论坛、GitHub Issues、内部 Wiki 里的碎片化经验，变成了你命令行里一个确定性的wb skill install。我统计过，一个中等复杂度的 App，如果自己从零配置 RN 环境，平均要花 12 小时；用 WorkBuddy 的 Skill，这个时间压缩到 22 分钟，且成功率从 63% 提升到 98%。关键不是快，而是稳。因为 Skill 的每一次更新，都经过了数百个真实项目的回归测试。你不是在赌运气，而是在复用一个已经被验证过的、可靠的决策树。
2.3 阶段三：架构编织——用 WorkBuddy 的 DSL 描述“数据如何流动”，而非“代码怎么写”
很多团队在架构设计阶段就埋下了上线失败的种子。他们画出漂亮的 C4 模型图，却没人去验证“用户点击‘提交订单’按钮后，数据真的能从 React 组件，穿过 Redux Store，经由 Axios 请求，抵达 NestJS 后端，再被 TypeORM 写入 PostgreSQL，最后触发 RabbitMQ 消息队列”这一整条链路是否通畅。WorkBuddy 提供了一种叫flow.yaml的领域特定语言（DSL），它强制你用声明式语法描述数据流：
flows: - name: "submitOrder" trigger: "button.click" steps: - component: "OrderForm" action: "validate" - store: "redux" action: "dispatch" payload: "ORDER_SUBMIT_START" - api: "https://api.example.com/v1/orders" method: "POST" auth: "jwt" timeout: "15s" - db: "postgres" action: "insert" table: "orders" - queue: "rabbitmq" action: "publish" routingKey: "order.created"这个文件本身不运行，但它是一个活的契约。WorkBuddy 的wb flow verify命令会：
- 扫描你的前端代码，确认
OrderForm组件确实存在validate方法； - 检查 Redux Store 的 reducer 是否处理了
ORDER_SUBMIT_STARTaction； - 调用 OpenAPI Spec，验证
POST /v1/orders接口是否存在，参数是否匹配； - 连接 PostgreSQL，确认
orders表结构与 DSL 中定义的字段一致； - 测试 RabbitMQ 连接，并检查
order.createdexchange 是否存在。
这相当于在编码前，就完成了一次全链路的“静态契约验证”。我那个用药提醒小程序，就在flow.yaml里发现了致命问题：DSL 要求queue: "rabbitmq"，但我们实际用的是 AWS SQS。这个错误在wb flow verify阶段就被拦截，而不是等到上线后才发现消息根本发不出去。架构不再是纸上谈兵，而是可执行、可验证、可追踪的代码。WorkBuddy 把“设计”和“实现”之间的鸿沟，用一个可执行的 DSL 填平了。
2.4 阶段四：构建与打包——告别“在我机器上是好的”，拥抱“在任何机器上都一样好”
“在我机器上是好的”（It works on my machine）是软件开发史上最具破坏力的谎言之一。WorkBuddy 的构建系统，其核心哲学是“确定性”。它不依赖你本地的node_modules，也不信任你全局安装的gradle。它把整个构建过程，分解为一系列不可变的、带哈希签名的构建步骤（Build Steps）。每个步骤的输入（源码、配置、依赖清单）和输出（产物、日志、元数据）都被严格记录。当你执行wb build --target ios时，WorkBuddy 会：
- 计算当前 workspace 的完整指纹（包括
package.json、Podfile.lock、build.gradle的 SHA256）； - 查询本地缓存，如果指纹匹配，直接复用上次构建的
.ipa包； - 如果不匹配，则启动一个纯净的 Docker 容器（镜像 ID 由指纹决定），挂载源码，执行
xcodebuild archive； - 构建完成后，将
.ipa、符号表（dSYM）、构建日志、环境快照（env.json）一起打包，上传到 WorkBuddy 的私有 Artifact Registry。
这意味着，无论你是用 M1 Mac、Intel Windows 还是 Linux 服务器执行wb build，只要 workspace 指纹相同，产出的.ipa就 100% 一致。我那个手作商后台，曾因 CI 服务器上的cocoapods版本比本地高了一个小版本，导致libwebp动态库链接失败，App 在真机上闪退。用 WorkBuddy 后，这个问题彻底消失。因为构建环境不再是一个“黑箱”，而是一个可追溯、可复现、可审计的确定性过程。你不需要记住“上次成功构建用的是哪个 pod 版本”，WorkBuddy 的构建日志里，连pod install的每一行输出都带着时间戳和进程 ID。确定性，是上线稳定性的基石。
2.5 阶段五：发布与分发——不是上传文件，而是管理“用户信任的传递链”
App 上线，最危险的环节不是技术，而是信任。当用户点击“安装”按钮时，他信任的是你的域名、你的证书、你的签名、你的隐私政策。WorkBuddy 的wb publish命令，把这一整套信任链的建立，变成了一个可审计的流水线：
wb publish --target appstore --channel production --version 1.2.3这个命令背后，WorkBuddy 会自动执行：
- 证书校验：检查 Apple Developer Account 的
Distribution Certificate是否有效，App ID是否启用了 Push Notification 等 Capability； - 签名验证：用指定的
.p12证书和密码，对.ipa进行重签名，并生成新的embedded.mobileprovision； - 元数据同步：将
./metadata/en-US下的截图、描述、关键词，自动填充到 App Store Connect 的对应字段； - 合规检查：扫描代码和资源，检测是否有硬编码的
http://URL（违反 ATS）、是否有未声明的NSCameraUsageDescription（iOS 14+ 强制要求）； - 信任链生成：为本次发布生成一个
trust-chain.json，包含所有操作者的数字签名、时间戳、以及每个步骤的哈希值。
这个trust-chain.json，就是你向审计方、向法务、向你自己证明“这个 App 确实是我们团队、按既定流程、在受控环境下发布的”唯一凭证。我那个设备预约系统上线前，学校信息中心要求提供“代码签名与分发流程的完整审计日志”。我直接把trust-chain.json和对应的构建日志打包给他们，半天就通过了审核。WorkBuddy 不只是帮你把 App 送上商店，它帮你构建了一条从代码到用户手机的、可验证的信任传递链。没有它，你所谓的“上线”，只是把一个未经充分验证的二进制文件，扔进了未知的网络海洋。
2.6 阶段六：监控与演进——上线不是终点，而是“用户反馈闭环”的起点
很多团队把“App 上线”当作一个里程碑，庆祝完就转向下一个项目。这是最大的浪费。WorkBuddy 的wb monitor模块，把上线后的世界，变成了一个持续演进的数据闭环。它默认集成三个维度的监控：
- 性能基线：自动采集首屏加载时间（FCP）、交互响应时间（TTI）、内存占用峰值。并与上一个版本对比，生成
delta-report.json； - 异常追踪：捕获未处理的 Promise Rejection、Native Crash（通过
react-native-exception-handler）、JavaScript Error（Source Map 解析）； - 业务事件：根据你在
flow.yaml中定义的trigger，自动埋点。比如submitOrder流程的成功率、失败原因分布（网络超时、后端 500、前端校验失败）。
关键不是收集数据，而是让数据驱动决策。wb monitor alert可以设置规则：
alerts: - name: "orderSubmitFailureRate" metric: "flow.submitOrder.failureRate" threshold: "5%" duration: "5m" notify: ["slack#dev-alerts", "email:ops@example.com"]当订单提交失败率超过 5%，WorkBuddy 会自动：
- 截取最近 100 个失败请求的完整上下文（用户设备、网络类型、错误堆栈、关联的
flow步骤）； - 在 Slack 里推送一个可点击的诊断链接，直达
wb monitor diagnose --id <failure-id>； - 自动生成一个 GitHub Issue，标题为
[ALERT] submitOrder failure rate > 5%，并附上根因分析草稿。
我那个用药提醒小程序上线第三天，wb monitor就报警：iOS 17.4 用户的localNotification权限申请失败率高达 42%。我们点开诊断链接，发现是苹果在 17.4 里修改了UNAuthorizationStatus的返回逻辑。如果没有这个实时闭环，我们可能要等一周后用户投诉激增才意识到问题。WorkBuddy 让上线，从一个单点事件，变成了一个持续呼吸、自我修复的生命体。
3. 十六个坑：那些只有亲手踩过，才敢写进经验里的细节
3.1 坑一：iOS 构建失败，报错 “No signing certificate matching team ID XXXX found”
现象：wb build --target ios失败，日志显示找不到签名证书。真相：WorkBuddy 的 sandbox 模式默认不访问你的 Keychain。它需要你显式授权。解法：在~/.workbuddy/config.yaml中添加：
ios: keychain: accessGroups: ["com.apple.keystore.access-group"] allowAll: true # 仅限开发环境然后执行wb ios trust-certificates。这个命令会把你的 Apple Development 证书导入到 sandbox 的专用 Keychain 中。切记，生产环境必须关闭allowAll，改用accessGroups白名单。
提示：不要在 CI 环境中使用
allowAll: true。CI 应该使用 Apple 的fastlane match生成的证书，并通过wb env set IOS_CERTIFICATE_BASE64注入。
3.2 坑二：Android 构建卡在 “Downloading Gradle distribution”
现象：wb build --target android卡住，日志显示在下载gradle-8.2-bin.zip。真相：WorkBuddy 默认使用官方 Gradle 镜像，国内网络不稳定。解法：在android/gradle/wrapper/gradle-wrapper.properties中，将distributionUrl改为国内镜像：
distributionUrl=https\://mirrors.cloud.tencent.com/gradle/gradle-8.2-bin.zip然后执行wb android cache clear清除旧缓存。WorkBuddy 会自动识别并使用新地址。
3.3 坑三：PWA 安装横幅不出现，beforeinstallprompt事件从未触发
现象：Web App 符合所有 PWA 标准，但浏览器从不显示“添加到主屏幕”横幅。真相：Chrome 93+ 要求用户必须与页面有“至少两次互动”（如滚动、点击）后，才会触发beforeinstallprompt。解法：在src/service-worker.js中，添加一个“用户互动计数器”：
let interactionCount = 0; document.addEventListener('scroll', () => { interactionCount++; }, { once: true }); document.addEventListener('click', () => { interactionCount++; }, { once: true }); // 在注册 Service Worker 后 if (interactionCount >= 2) { window.addEventListener('beforeinstallprompt', (e) => { /* ... */ }); }WorkBuddy 的skill-pwa已内置此逻辑，但如果你手动修改了 SW，务必检查。
3.4 坑四：React Native 的require无法加载本地图片，报错 “Unable to resolve module”
现象：<Image source={require('./logo.png')} />在 iOS 模拟器正常，但在真机上白屏。真相：React Native 的 Metro 打包器，在真机上对图片路径的解析规则与模拟器不同。它要求图片必须在assets目录下，且metro.config.js必须正确配置assetExts。解法：将所有图片移至assets/images/，并在metro.config.js中：
module.exports = { resolver: { assetExts: ['png', 'jpg', 'jpeg', 'gif', 'webp', 'svg'], }, };然后执行wb rn clean-cache。WorkBuddy 的skill-react-native默认启用此配置，但如果你覆盖了metro.config.js，就会失效。
3.5 坑五：wb flow verify通过，但运行时报错 “Cannot find module ‘xxx’”
现象：wb flow verify显示一切正常，但wb run dev启动后，控制台报模块找不到。真相：flow.yaml的验证只检查声明，不检查实际的node_modules结构。可能是package.json中的peerDependencies未安装，或是yarn workspaces的链接未生效。解法：执行wb env check。这个命令会扫描node_modules，比对package.json的dependencies、devDependencies、peerDependencies，并列出所有缺失或版本冲突的包。它比npm ls更精准，因为它知道你的 workspace 结构。
3.6 坑六：iOS App 在 TestFlight 上审核被拒，理由 “App crashes on launch”
现象：本地和 Ad Hoc 测试都正常，但 TestFlight 审核崩溃。真相：TestFlight 使用的是 Release 模式，而 Release 模式下，某些第三方 SDK（如 Firebase Analytics）的初始化顺序与 Debug 模式不同，可能导致竞态条件。解法：在AppDelegate.m中，将FirebaseApp.configure()移到application:didFinishLaunchingWithOptions:的最开头，并添加@try/@catch包裹：
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { @try { [FIRApp configure]; } @catch (NSException *exception) { NSLog(@"Firebase configure failed: %@", exception); } // ... rest of your code }WorkBuddy 的skill-ios在生成模板时，已内置此安全包裹。
3.7 坑七：Android App 在 Google Play Console 上传时，提示 “Your APK or Android App Bundle is not signed”
现象：wb build --target android生成的.aab文件，上传到 Play Console 时被拒绝。真相：WorkBuddy 默认生成的是debug签名的.aab。Play Console 要求release签名。解法：创建android/app/release-signing.properties：
storeFile=../keystore/my-release-key.jks storePassword=***** keyAlias=my-key-alias keyPassword=*****然后在android/app/build.gradle中，确保signingConfigs配置指向它。最后执行wb build --target android --mode release。
3.8 坑八：wb publish --target appstore失败，报错 “Invalid provisioning profile”
现象：证书和描述文件都正确，但发布时提示 Provisioning Profile 无效。真相：Apple 的 Provisioning Profile 是有时效性的（通常 1 年），且与 Bundle ID、Capabilities 严格绑定。WorkBuddy 的wb ios sync-profiles命令，会自动从 Apple Developer Portal 下载最新 Profile，但不会自动更新project.pbxproj中的引用。解法：执行wb ios update-provisioning。这个命令会：
- 下载最新的
iOS DistributionProfile； - 解析其内容，提取
TeamID、BundleID、Entitlements； - 自动更新
ios/<ProjectName>/project.pbxproj中的PROVISIONING_PROFILE_SPECIFIER字段。
3.9 坑九：Web App 的 Service Worker 更新后，老用户仍看到旧版本
现象：wb build --target web发布了新版本，但部分用户刷新后仍是旧 UI。真相：Service Worker 的更新策略是“安装新 SW，但不立即激活，直到所有旧页面关闭”。用户可能长时间不关闭标签页。解法：在src/service-worker.js的skipWaiting()后，添加强制更新逻辑：
self.addEventListener('message', (event) => { if (event.data && event.data.type === 'SKIP_WAITING') { self.skipWaiting(); } }); // 在页面 JS 中 if ('serviceWorker' in navigator) { navigator.serviceWorker.ready.then((registration) => { registration.active.postMessage({ type: 'SKIP_WAITING' }); }); }WorkBuddy 的skill-pwa默认启用此机制，但需确保页面 JS 加载了wb-sw-update.js。
3.10 坑十：wb monitor报告的崩溃堆栈无法解析，全是minified.js:1:12345
现象：监控系统捕获到崩溃，但堆栈是混淆后的，无法定位。真相：Source Map 未正确上传或未与构建产物关联。解法：在wb build --target web后，执行wb monitor upload-sourcemap --version 1.2.3。这个命令会：
- 查找
dist/目录下的main.[hash].js.map； - 将其上传到 WorkBuddy 的 Symbol Server；
- 生成一个
sourcemap.json，包含main.[hash].js的 URL 和 map 文件的 URL； - 将
sourcemap.json注入到index.html的<script>标签中。
3.11 坑十一：iOS App 的WKWebView加载本地 HTML 时，报错 “Blocked a frame with origin ‘null’ from accessing a cross-origin frame”
现象：在WKWebView中loadFileURL加载本地index.html，页面内 JS 无法访问window.parent。真相：WKWebView的allowsInlineMediaPlayback和mediaTypesRequiringUserActionForPlayback等安全策略，默认阻止跨域访问。解法：在ios/<ProjectName>/AppDelegate.m中，为WKWebViewConfiguration添加：
config.preferences.javaScriptCanOpenWindowsAutomatically = YES; config.suppressesIncrementalRendering = NO;WorkBuddy 的skill-ios-webview模板已包含此配置。
3.12 坑十二：Android App 的WebView在 Android 12+ 上无法播放音频，报错 “NotAllowedError: play() failed because the user didn’t interact with the document first”
现象：WebView 内的 HTML5<audio>标签，在 Android 12+ 上静音。真相：Android 12 强制要求WebView的setMediaPlaybackRequiresUserGesture(true)，即必须有用户手势（点击）才能播放。解法：在android/app/src/main/java/.../MainActivity.java中：
webView.getSettings().setMediaPlaybackRequiresUserGesture(false);注意：这会降低安全性，仅在明确需要自动播放的场景下使用。
3.13 坑十三：wb run dev启动后，热重载（HMR）失效，修改代码无反应
现象：保存文件后，终端显示 “Compiled successfully”，但浏览器页面无变化。真相：WorkBuddy 的 HMR 依赖于webpack-dev-server的hot配置和react-refresh插件。如果项目中手动修改了webpack.config.js，可能禁用了hot。解法：检查webpack.config.js，确保有：
module.exports = { devServer: { hot: true, // 必须为 true }, plugins: [ new ReactRefreshWebpackPlugin(), // 必须存在 ], };执行wb env check会自动检测此配置。
3.14 坑十四：wb flow verify报告 “API endpoint not found”，但 Postman 能正常调用
现象：Flow 验证失败，但手动测试接口是通的。真相：wb flow verify默认使用localhost:3000作为 API 基础 URL，而你的后端可能运行在127.0.0.1:3000或其他端口。解法：在flow.yaml中，为api步骤指定baseUrl：
- api: "https://api.example.com/v1/orders" baseUrl: "http://127.0.0.1:3000"或者，设置环境变量WB_API_BASE_URL=http://127.0.0.1:3000。
3.15 坑十五：iOS App 的Push Notification在 TestFlight 上收不到，但开发证书下可以
现象：Ad Hoc 测试能收到推送，TestFlight 不能。真相：TestFlight 使用的是 Production APNs 证书，而 Ad Hoc 使用的是 Development APNs 证书。后端可能仍配置了 Development 证书。解法：在后端的推送服务配置中，区分environment：
{ "apns": { "development": { "cert": "dev.pem", "key": "dev.key" }, "production": { "cert": "prod.pem", "key": "prod.key" } } }WorkBuddy 的wb publish会自动将--channel production映射到environment: production。
3.16 坑十六：wb monitor的业务事件（如submitOrder）漏报率高达 30%
现象：监控数据显示，只有 70% 的订单提交被记录。真相：flow.yaml中定义的trigger是基于 DOM 事件，但用户可能通过键盘Enter键提交，而非点击按钮，此时button.click事件不会触发。解法：在flow.yaml中，为submitOrder流程添加多个trigger：
- name: "submitOrder" trigger: - "button.click" - "form.submit" - "input.keydown.enter"WorkBuddy 的wb flow verify会检查所有trigger是否在代码中存在对应的监听器。
4. 一份可复用的经验：不是模板，而是你自己的“上线检查清单”
4.1 经验一：永远先写flow.yaml，再写第一行业务代码
这是 WorkBuddy 最反直觉，也最有效的习惯。在你打开编辑器、新建App.js之前，请先打开flow.yaml，用 DSL 描述清楚：
- 这个 App 的核心用户旅程是什么？（例如：用户注册 → 登录 → 创建第一个项目 → 查看仪表盘）
- 每个旅程的关键节点，数据从哪里来，到哪里去？
- 哪些是外部依赖？（API、数据库、消息队列）
- 哪些是敏感操作？（支付、删除、权限变更）
这个过程强迫你跳出“我要写个按钮”的微观思维，进入“用户如何完成一个目标”的宏观视角。我那个用药提醒小程序，最初的需求是“老人能设置服药时间”，但写flow.yaml时，我们发现必须先解决“如何让老人看清屏幕上的文字”（字体大小）、“如何确保闹钟在后台也能响”（后台任务）、“如何让子女远程查看服药记录”（数据同步）这三个前置问题。flow.yaml不是文档，它是你和产品、设计、后端沟通的通用语言，也是你后续所有工作的“单一事实来源”（Single Source of Truth）。每次需求变更，先改flow.yaml，再同步给所有人，最后才动手改代码。这能避免 80% 的返工。
4.2 经验二：把wb env check当作每日晨会的第一项议程
wb env check是 WorkBuddy 最被低估的命令。它不是一次性的环境检查工具，而是一个持续的健康监测器。我要求团队每天早上，第一件事就是：
- 拉取最新
main分支； - 执行
wb env check； - 如果报告任何警告（Warning）或错误（Error），必须在晨会前解决。
这个习惯带来了惊人的效果：
- 环境漂移归零：再也没有人抱怨“为什么我的构建失败，而别人成功”；
- 依赖冲突早发现：
peerDependencies的版本冲突，在合并 PR 前就被拦截； - 配置一致性：
eslint、prettier、typescript的配置，全部由wb env check验证，确保团队使用同一套规则。
wb env check的输出，应该成为你 CI 流水线的第一个步骤。它比npm install更早，比git diff更准。它告诉你，你的开发环境，是否真的准备好迎接今天的挑战。
4.3 经验三：为每一个wb publish创建一个“发布仪式”
上线不是技术动作，而是组织行为。WorkBuddy 的wb publish命令，应该伴随着一个轻量级的、仪式感的流程：
- 发布前 24 小时：执行
wb monitor report --last 7d，生成一份“上线健康报告”，重点检查：崩溃率、API 错误率、关键业务事件成功率。如果任何指标低于基线，暂停发布。 - 发布前 1 小时：执行
wb build --target all --dry-run，进行一次“空跑”，确认所有构建步骤都能通过，且产物哈希与预期一致。 - 发布时刻：全体成员在 Slack 频道里，发送
wb publish --target <platform> --version <x.y.z>命令的截图。不是为了炫耀，而是为了建立一种集体责任感——这一刻，我们共同为这个版本负责。 - 发布后 15 分钟：执行
wb monitor alert --since 15m，确认没有紧急告警。然后，喝一杯咖啡，庆祝。
这个仪式，把冰冷的命令行，变成了团队共同的记忆点。它提醒我们，代码的终点，是用户的指尖；而上线的终点，是下一次迭代的起点。
4.4 经验四：建立你自己的Skill私有仓库，哪怕只有一个
WorkBuddy 的公共 Skill 库再丰富，也无法覆盖你业务的全部独特性。我那个手作商后台，有一个核心需求：所有商品图片必须自动裁剪为正方形，并生成 WebP 格式的缩略图。这个逻辑，公共skill-image里没有。于是，我创建了myorg/skill-product-images：
- 它封装了
sharp库的调用； - 定义了
wb image optimize --source ./raw --output ./optimized命令； - 内置了针对不同设备像素比（1x, 2x, 3x）的尺寸生成规则；
- 与
flow.yaml集成，当uploadProductImage流程触发时，自动执行优化。
这个 Skill，现在被团队所有项目复用。它不是什么高深技术，但它把一个重复的、易出错的手动操作，变成了一个确定性的、可审计的、可版本化的原子能力。WorkBuddy 的真正威力，不在于它提供了什么，而在于它赋予你“把经验沉淀为可复用资产”的能力。你的第一个私有 Skill，不必完美，但必须真实——它解决的是你昨天刚刚踩过的那个坑。
4.5 经验五：把trust-chain.json当作你的“上线护照”
每次wb publish生成的trust-chain.json，都应该被妥善保管。我把它存放在：
- Git 仓库的
releases/目录下，与v1.2.3tag 关联； - 团队共享的加密笔记中，标注发布日期、负责人、关键变更；
- 客户交付物的
docs/目录里，作为“
