领航项目工作流

要解决的问题

在微信小程序 + 腾讯云开发（CloudBase）的项目里，一次上线往往会同时牵扯代码仓库、Release 包、云函数、数据库集合和 Issue/PR。常见的失败模式是：老板甩来一个 zip 包说“以这个为准”，本地仓库、release 包、线上云函数三份代码各说各话；或者安全修复做完后，没人审查就直接部署；又或者 tcb CLI 部署时 --dir 指向了父目录，跑起来才发现函数入口不对。这套技能就是把这类多步骤、易错的操作固化成可复用的流程。

技能如何工作

技能按场景组织，每个场景对应一类真实触发条件：

• Release 包覆盖仓库代码：对 zip 包与仓库做差异对比，报告区分仅 release 有、仅仓库有、两边都有但内容不同的文件，并逐文件给出关键 diff，最后按安全修复、功能差异、遗留文件分类，并给出合并方向建议。
• 安全修复 + NPC 审查：先在本地直接改文件、commit + push 并完成修复后的必要动作，再通过 CNB API 创建 Issue 派给 assignees: cnbnn、priority: P1，随后检查 NPC 反馈、合并 PR 并关闭 Issue。
• 云函数部署：支持单个与批量部署，部署前先做检查，也支持清理遗留云函数。
• 数据库集合与索引：集合用 @cloudbase/node-sdk 的 createCollection() 创建，索引和 TTL 索引走 tcb db nosql execute 加 createIndexes，TTL 的 expireAfterSeconds 写在 indexes 定义里，之后做验证与集合列表检查。
• 发布 Release 与 仓库治理：批量关闭 Issue 时 state_reason 只能取 completed / not_planned / reopened。
• 代码审查兜底：当 Claude Code/Codex 不可用时，用本地自审清单覆盖云函数参数校验、防暴力破解、防重复提交、事务内 _.inc() 原子操作、隐私字段（_openid、手机号）不外泄，以及前端 wx:key 用 _id 等检查点。

适用边界与注意点

CNB API 的路径和字段坑很多：创建 Issue 是 POST /{repo}/-/issues，不是 /repos/{repo}/issues；PR 合并要传 merge_style 和必填的 commit_title，没有 merge_method；关闭 Issue 必须 state 与 state_reason 同时传；PR 文件用 GET /{repo}/-/pulls/{n}/files，.diff 不返回内容。认证头是 Authorization: Bearer $CNB_TOKEN，响应要带 Accept: application/vnd.cnb.api+json，否则可能直接报错。

CloudBase 侧同样有认知偏差：集合不存在时 .add() 会直接报错，不会自动创建；CLI 没有直接的创建集合命令；db model push 不能创建新模型；TTL 索引只能走 CLI，SDK 不支持；tcb fn deploy --dir 必须指向包含 index.js 的目录。

环境依赖是前置条件：tcb CLI v3.2.2 用于部署和数据库操作，@cloudbase/node-sdk 用于创建集合（已在 /tmp 安装），CNB_TOKEN 写在 ~/.bashrc 里但当前 shell 可能没 export，tcb login --key 完成认证。另外 tcb CLI invoke 不带 openid，只能验证参数校验，测不了完整业务链路。

这套流程的价值在于把“该敲什么命令、该检查什么字段”显式写出来，而不是依赖记忆。