把 cc-connect 接到飞书，再让 Codex 或 Claude Code 在本地仓库里干活，真正难的不是“能不能回一句话”，而是这条链路能否按生产标准验收：安装顺序明确、权限边界可解释、飞书事件与卡片回调完整、会话不会串线、长任务有进度语义，出问题时能从日志和守护进程状态里定位。cc-connect 的定位是本地 AI Agent 与即时通信平台之间的桥。飞书长连接模式由本地进程主动连到飞书 WebSocket 网关，不要求公网 IP、域名、反向代理或 VPS。因此这套方案通常应先在开发者自己的电脑、内网工作站或团队受控主机上跑通；除非你本来就要把某台远程工作站当作 Agent 宿主，否则不要为了飞书接入单独购买服务器。
先定验收目标：聊天入口不是生产能力本身
生产验收要回答四个问题。第一，用户从飞书发出的消息是否只会进入被允许的项目与被允许的 Agent；第二，Agent 的工具权限、工作目录和管理员命令是否有清晰边界；第三，消息、图片、文件、卡片按钮、权限确认、进度更新和完成通知是否都走到预期路径；第四，cc-connect 作为常驻进程能否重启、升级、回滚和观察。只测试“@机器人，机器人能回 hello”没有意义，因为真正的风险往往藏在多用户群聊、连续图片、长时间空闲后的上下文漂移、卡片按钮缺回调、错误权限放在错误 TOML 层级，以及把 `cc-connect web` 误认为服务启动命令。
本文按验收手册来组织，不按宣传功能清单来写。建议把每一项都变成发布前 checklist，并记录命令输出、飞书开放平台截图、配置片段、日志片段和一次真实群聊演练结果。cc-connect 当前源码 main 位于 a5c93d9ce1993f7ce136ef454e3f80324758cc1a，npm 包版本标记为 1.5.1-beta.1；公开 release 中稳定线是 v1.5.0，预发布线是 v1.5.1-beta.1。生产接受时应把这两个事实分开：稳定环境默认取 1.5.0；如果需要 beta 中的 Feishu 大文件分块下载、Claude Code /compact 修复、Codex 失败 turn 传播、max reasoning effort、daemon 非 Linux 修复等改动，才有理由接受 beta，并在回滚预案里写明。
版本、许可证与源码事实先入档
验收第一步不是安装，而是把来源事实写进变更单。仓库原始地址应记录为 https://github.com/chenhg5/cc-connect。main 分支在本次检查点是 a5c93d9ce1993f7ce136ef454e3f80324758cc1a，但 GitHub API 显示仓库默认分支仍在继续更新，开放 issue 数量很高，说明主线与 release 之间存在持续漂移。验收文档里不要写“已完全稳定”“无已知问题”这类不可证明表述；应写“按当前锁定版本验收，后续升级需重新跑矩阵”。
许可证也要单独记录。README 与 npm package 声称 MIT，但本次源码树根目录没有观察到 LICENSE 文件；GitHub API 的 license 字段为 null。这不等于项目一定不能使用，也不等于 README 的 MIT 声明必然无效，但对企业内审来说，它意味着不能只截图 README 里的 MIT 字样就算通过。生产采用前应把这一点列为法务/合规 caveat：当前观察到“README 声称 MIT、npm 元数据 license 为 MIT、仓库 API 未识别许可证、根目录未见 LICENSE 文件”。如果组织要求 SPDX 可机读许可证或完整许可证正文，应在引入前向维护者确认或自行留存风险接受记录。
安装顺序：先 Agent，再认证，再 cc-connect
cc-connect 本身只是桥。它启动后要拉起 Claude Code、Codex、Gemini、Cursor Agent 等本地 CLI。如果先装 cc-connect、后装 Agent，常见结果是服务退出、Web UI 没起来，日志里出现类似 claude CLI not found in PATH 或所选 Agent 找不到。生产手册必须写死顺序：先安装至少一个 Agent CLI；再用该 Agent 的交互式登录流程完成认证；确认命令在同一个运行用户的 PATH 中可见；最后安装和启动 cc-connect。
# 例：Claude Code
brew install --cask claude-code
claude --version
claude login
# 例：OpenAI Codex
npm install -g @openai/codex
codex --version
codex login
# 最后安装 cc-connect
npm install -g cc-connect
# 或 brew install cc-connect
cc-connect --version这里有一个很容易在生产里踩的坑：认证凭据属于运行 cc-connect 的 OS 用户。你用自己的桌面账号登录 Claude Code，但实际用 launchd、systemd 或另一个服务账号启动 cc-connect，Agent 进程可能看不到同一份凭据。若启用 run_as_user 做 OS 用户隔离，还要把目标用户自己的 Claude/Codex 配置、认证文件、Git 凭据、SSH key、语言工具链和项目目录读写权限都准备好。验收时不能只在当前 shell 里执行 claude --version；还应以最终服务用户执行同样命令，并让它在目标 work_dir 内跑一次只读任务。
cc-connect 第一次启动与 Web UI 边界
第一次运行 cc-connect 会创建默认配置，并打印 Web admin 地址，默认是 http://localhost:9820。如果端口冲突，可以指定 Web 端口或修改配置。验收记录里要把“启动服务”和“打开配置界面”拆成两条命令。cc-connect 才是启动服务；cc-connect web 只负责打开浏览器和配置界面，不会启动后台服务。很多现场问题都来自把 cc-connect web 放进守护进程或启动脚本，结果界面打开过，机器人却从未连接飞书。
# 正确：启动服务进程
cc-connect -config ~/.cc-connect/config.toml
# 仅用于打开或配置 Web 管理界面，不启动服务
cc-connect webWeb UI 可以用来创建项目、添加平台、管理 provider 和测试聊天，但生产配置不能只停留在“界面能保存”。必须回到配置文件或管理 API 检查最终字段：项目名、Agent 类型、工作目录、provider、Feishu app_id/app_secret、allow/admin 边界、卡片开关、线程隔离、进度样式、图片合批窗口和空闲 reset。界面与配置文件之间的热加载也要验收：保存后日志应出现 reload 或平台重启信号；若没有，重启 cc-connect 并记录重启方式。
Feishu 接入：优先长连接，不要为了 Webhook 搭公网入口
飞书接入推荐 WebSocket 长连接。这个模式由 cc-connect 主动连到飞书开放平台，开放平台把事件沿长连接推回本地进程；本机不需要公网 IP、HTTPS 域名、Nginx、frp、ngrok 或云服务器。Webhook 模式才需要公网 URL 与回调验证。对 cc-connect + Feishu + 本地 Agent 的主流用法，生产验收应明确“无公网入口”是设计约束，不是缺陷。
飞书配置可以用 CLI 辅助完成：
cc-connect feishu setup --project my-project
# 已有应用凭证时：
cc-connect feishu setup --project my-project --app cli_xxx:sec_xxxCLI 的 setup 是统一入口：没有凭证时走扫码新建；带 --app 时绑定已有应用。它会尽量写回 config.toml，并在新建流程中让飞书预配部分权限和事件订阅。但生产验收不能把 CLI 成功当作飞书后台已合格。仍要进入飞书开放平台核验应用状态、机器人能力、权限、事件订阅、回调订阅、发布版本和可用范围。飞书后台任何一次权限或事件修改，都可能需要重新创建版本并发布，未发布配置不会进入真实消息链路。
最小可用配置与字段位置
一个可验收的项目配置大致如下。真实生产中应避免把 secret 写进截图或文档；可以用环境变量替代，但验收时要证明服务进程能解析这些变量。
[[projects]]
name = "repo-codex"
admin_from = "ou_admin_open_id"
reset_on_idle_mins = 30
[projects.agent]
type = "codex" # 或 claudecode
[projects.agent.options]
work_dir = "/Users/team/workspace/repo"
mode = "suggest"
reasoning_effort = "high"
[[projects.platforms]]
type = "feishu"
[projects.platforms.options]
app_id = "cli_xxx"
app_secret = "${FEISHU_APP_SECRET}"
allow_from = "ou_user_a,ou_user_b"
allow_chat = "oc_group_chat_id"
enable_feishu_card = true
thread_isolation = true
progress_style = "card"
ack_emoji = "Get"
reaction_emoji = "OnIt"
done_emoji = "Done"
image_batch_window_ms = 800最关键的位置规则是：admin_from 必须放在 [[projects]] 层级，不要放进 [projects.platforms.options]。它控制 /dir、/shell、/restart、/upgrade、添加可执行命令、添加 cron exec 等特权命令。allow_from 与 allow_chat 属于飞书平台配置，用来限制哪些用户和群可以触发机器人。两者不是同一个边界：允许使用机器人不等于允许执行管理命令；能执行管理命令也不应自动扩大群聊可见范围。
权限与事件：消息、发送、卡片回调缺一不可
飞书开放平台至少要启用机器人能力，添加消息接收事件 im.message.receive_v1，授予发送消息权限 im:message:send_as_bot，并按使用场景授予单聊、群聊、群成员、用户基础信息等读取权限。若希望群里未 @ 机器人的消息只作为下一次触发的上下文，则还要申请敏感权限 im:message.group_msg，并在 cc-connect 中打开 group_chat_history_share。这个功能不回溯 cc-connect 启动前历史，也不会让未 @ 消息自己触发回复；验收时要把它与“群聊无需 @ 全量响应”的配置区分开。
如果启用交互卡片，必须订阅卡片回调 card.action.trigger，并选择长连接接收回调。卡片用于权限确认、provider 切换、导航按钮、进度卡等交互。缺少回调时，用户点击按钮可能看到加载超时，Agent 侧却没有任何有效输入。暂时拿不到卡片回调权限时，应显式设置 enable_feishu_card = false，让交互退回纯文本，而不是在半残状态下上线。
allow 与 admin：生产边界要按人、群、命令三层验收
cc-connect 接入飞书后，所有消息都来自一个聊天平台，但生产边界至少分三层。第一层是平台入口：allow_from 控制哪些 open_id 能触发，allow_chat 控制哪些群能触发，group_only 可禁止私聊。第二层是项目管理：admin_from 控制谁能改目录、跑 shell、重启、升级和写可执行命令。第三层是 Agent 自身工具权限：Claude Code 的 default、acceptEdits、bypassPermissions，Codex 的 suggest、auto-edit、full-auto、yolo 等模式决定工具调用如何审批。
验收矩阵应覆盖正反两面：允许用户在允许群里 @ 机器人能触发；未允许用户不能触发；允许用户在未允许群里不能触发；普通允许用户不能执行 /shell 或 /dir；管理员能执行 /whoami、/status、/dir，但只有在 Agent 权限模式允许时才会发生实际文件或命令操作。若使用 admin_from = "*"，变更单必须写明这是单人私用或受控测试，不应作为多人群聊默认配置。
Codex 与 Claude Code 的模式验收
Claude Code 与 Codex 都能接入，但权限语义并不完全相同。Claude Code 的默认模式会对工具调用请求确认；acceptEdits 允许编辑类操作自动通过；bypassPermissions/yolo 会放开更多能力，适合一次性私人环境，不适合多人生产群。Codex 的 suggest 偏只读或保守，auto-edit 会让模型判断何时请求，full-auto 在沙箱内自动执行，yolo 绕过审批和沙箱。cc-connect 源码中 Codex 默认 exec backend 对交互式审批能力有限，若需要真实交互 approval，应评估 app_server backend，而不是只看模式名。
验收时给 Agent 发三类任务：只读分析、可控编辑、危险命令。只读任务应无需人工审批并能返回仓库结构；可控编辑应按预期请求或自动通过；危险命令例如删除目录、读取敏感文件、访问 sibling 项目，应被 Agent 模式、允许工具、OS 用户权限或人工审批拦住。对于 Claude Code PermissionRequest hooks，要额外验证 hook 结果能被 cc-connect 使用；若 hook 调 LLM，还要避免在 Claude Code 与 cc-connect 两边重复消耗。
线程隔离：群聊生产化的核心开关
飞书群聊的自然形态是多人、多话题、多轮穿插。如果所有人共享一个 session，Agent 很容易把 A 的修复上下文带到 B 的问题里，或者把上一个项目目录误用到下一条消息。thread_isolation = true 后，飞书根消息或 reply thread 会成为会话边界；在 multi-workspace 模式下，每个话题还可以独立绑定 workspace。生产群聊建议默认开启，并要求用户在同一任务内使用回复串，而不是不断在主频道发新消息。
验收方法很简单：在同一个群里创建两个根消息，一个要求分析后端目录，一个要求分析前端目录；分别在两个 reply thread 中继续追问。机器人应保持两个独立上下文，不应把另一条线程的目录、文件名或待办带过来。再测试一个附件场景：已 @ 机器人激活的线程里，后续追加图片或文件即使没有再次 @，也应能进入同一线程；未激活线程的附件不应静默触发后台工作。
进度、确认与完成：ack/reaction/done 不要混成一个含义
长任务体验要靠三个不同语义支撑。ack_emoji 表示消息已通过校验、被引擎接受处理或入队，它不表示 Agent 已开始执行，也不表示任务成功；权限过滤、重复/过时消息、满队列拒绝、已由 cc-connect 自己处理的命令不会产生确认。reaction_emoji 表示 Agent 正在处理，通常是临时状态，结束后会移除。done_emoji 表示本轮完成，适合 quiet 或卡片原地更新场景，因为飞书客户端不一定对卡片更新产生明显推送。
progress_style 决定中间过程怎么显示。legacy 会逐条发送思考和工具进度，信息密度高但容易刷屏；compact 合并到较少消息；card 使用结构化卡片更新，更适合飞书生产群。验收时要分别制造短任务、长命令、工具失败和权限请求：短任务不应残留“处理中”；长任务应能看到持续进度或至少有 ack；失败任务应有失败状态而不是永久卡在进行中；完成后 done 的语义不能被误写成“验收成功”。
多图合批：移动端连续发图不是一个事件
飞书手机端连续发送多张图片时，平台往往把每张图作为独立事件推送。如果不合批，Agent 可能对每张图各跑一轮，既浪费 token，也会把本来属于同一问题的截图拆散。image_batch_window_ms 用来设置同一会话内连续图片的合并窗口，默认约 500ms。网络慢或手机端发送间隔偏长时，可以调到 800–1200ms；如果主要是单图、追求响应速度，则可以降低。设置为 0 会回到默认窗口。
生产验收要用真实飞书客户端连发三张截图：例如一张报错、一张配置、一张日志。预期结果是 Agent 收到一个包含多图的任务，并在最新那条批次主消息上产生确认，而不是三轮互相打断的回答。还要测试“图片 + 文本说明”的顺序：文本先到、图片后到，或图片先到、文本后到时，团队是否有明确使用约定。对截图中可能包含密钥、客户数据或内部路径的场景，应在群规里要求先脱敏，因为 cc-connect 会把附件交给本地 Agent 处理。
空闲会话 reset：防止上下文漂移
cc-connect 默认建议在用户长时间不活动后切换到新会话，典型配置是 reset_on_idle_mins = 30。这不是检测 Agent 卡死的 idle_timeout_mins，而是防止用户隔很久回来后继续吃到旧 transcript。长时间调试、失败命令、废弃思路和已关闭 issue 一旦被反复 --continue 进新任务，会导致模型注意力漂移，尤其在飞书这种随手发消息的入口里更明显。
验收时要明确团队希望的策略。生产协作群建议保留默认 reset，并教育用户需要继续旧任务时用 /list 与 /switch。个人单线程工作流如果强依赖连续上下文，可以设置 reset_on_idle_mins = 0，但要承担旧上下文污染的风险。测试方法是：完成一轮任务后等待超过阈值，再发一个新主题，确认它创建新 session；同时旧 session 仍可从列表中找到，而不是被删除。
守护进程与日志：服务要能被系统接管
生产环境不应依赖一个手开的终端窗口。cc-connect 提供 daemon 命令，可安装为 systemd user/system service 或 macOS launchd LaunchAgent。基本验收命令包括：
cc-connect daemon install --config ~/.cc-connect/config.toml
cc-connect daemon start
cc-connect daemon status
cc-connect daemon logs -f
cc-connect daemon restart
cc-connect daemon stop守护进程验收至少要覆盖四件事：重启后能重新连上飞书 WebSocket；配置文件中的环境变量在 daemon 环境里可解析；日志轮转不会无限增长；服务用户与 Agent 认证用户一致或显式隔离。Linux 服务器如果没有 systemd 用户会话，可能需要 root 级安装、开启 linger，或使用 tmux/nohup 作为临时替代，但替代方案也要写进恢复流程。macOS 上要检查 launchd plist 是否能处理路径中的特殊字符、日志文件位置是否可写。
飞书 WebSocket 与 bot open_id：失败要 fail-closed
飞书群消息过滤依赖机器人身份识别。当前 beta 变更中特别提到“bot open_id discovery 失败时 fail-closed”，这是生产上更安全的行为：如果无法确认消息是否 @ 了本机器人，宁可不处理，也不要在群里静默消费所有消息。验收时要在日志里找 platform started、connected to wss://msg-frontier.feishu.cn、bot open_id 识别成功等信号；如果识别失败，检查 app_id/app_secret、权限、飞书域名、网络代理和应用发布状态。
长连接断开后的自动重连也要演练。可以短暂断网或停止服务后恢复，观察是否重新连接、是否漏处理恢复前后的消息、是否产生重复回复。对生产群，建议把“服务不可用时用户看到什么”写清楚：是没有 ack、没有 reaction，还是有监控告警。ack/reaction 的存在可以帮助一线用户判断消息是否进入队列，但它不能替代服务级监控。
卡片渲染与回退：不要让漂亮卡片掩盖失败
飞书卡片支持 Markdown、进度面板、权限按钮、provider/model 切换等更好的交互，但它也引入了额外的 API 限制、卡片实体、Patch 更新、表格数量限制和回调要求。生产验收要测试正文 Markdown、代码块、表格、长链接、本地文件引用、权限确认按钮、provider 选择按钮以及失败回退。长表格或复杂 Markdown 超出卡片限制时，应能回退到可读文本，而不是空白卡片。
如果使用 progress_style = "card"，还要验证飞书客户端、Web 端和移动端显示一致性。卡片原地更新在视觉上清爽，但不一定触发明显通知，因此建议配合 done_emoji。如果组织不允许交互卡片或权限没批下来，宁可用纯文本模式上线，之后再单独验收卡片能力。
文件、图片与生成附件回传
cc-connect 支持 Agent 生成本地图片、PDF、报告、日志包后通过 cc-connect send --image/--file 回传到当前聊天。Feishu 与 Telegram 是当前明确支持的附件回传平台。生产验收要区分“用户发给 Agent 的附件”和“Agent 生成后回传的附件”：前者依赖平台下载权限、大小限制和媒体解析；后者依赖本地文件存在、当前会话上下文、attachment_send 开关和平台上传限制。
cc-connect send --image /absolute/path/to/chart.png
cc-connect send --file /absolute/path/to/report.pdf
cc-connect send --file /absolute/path/to/report.pdf --image /absolute/path/to/chart.png验收要求使用绝对路径，因为 Agent 的当前工作目录可能随着 /dir 或线程 workspace 变化。还要测试超过大小限制的文件、被 attachment_send = "off" 禁止的情况、文件不存在的错误提示，以及图片中含敏感信息时的审计责任。不要让 Agent 自动把任意构建产物、密钥文件或数据库导出回传到群里。
多项目与工作目录：不要让 /dir 变成越界入口
cc-connect 一个进程可以管理多个项目，也能在聊天里用 /dir 切换目录。生产中这既方便，也危险。work_dir 应尽量指向单个仓库或受控根目录，不要直接设成用户 home 或整个 workspace。/dir 只能给管理员用，且每次切换后要通过 /status 或回复 footer 显示当前目录。执行 /dir reset 时，cc-connect 会恢复配置里的 work_dir 并清除持久化的目录覆盖状态；这条命令应放入故障恢复手册。
如果使用 multi-workspace 模式，频道名到目录的映射、/workspace init 是否允许本地路径、是否允许克隆任意 Git URL，都要单独定边界。Feishu 的 thread_isolation 与 multi-workspace 结合时，每个话题可以独立绑定 workspace，这很适合多任务协作，但验收矩阵必须证明一个 thread 的 workspace binding 不会影响同群其他 thread。
Provider、模型与运行时切换
cc-connect 支持在项目里配置 provider，并通过聊天命令切换。Claude Code 通常映射到 Anthropic 兼容环境变量；Codex 通常映射到 OpenAI 兼容的 OPENAI_API_KEY 与 OPENAI_BASE_URL。生产验收要把 provider 列表、默认 provider、可切换模型、计费账户和速率限制写清楚。不要让所有群成员都能随意切到高成本模型或未知代理。
建议预先配置 alias，例如 sonnet、codex、fast，并用 /model 验证展示结果。Codex 的 /reasoning 能切换推理强度时，要确认它是否被当前 backend 和版本实际支持。v1.5.1-beta.1 提到 Codex 支持 max reasoning effort、失败 app-server turns 能传播；如果这些能力是上线原因，就必须用 beta 环境做失败任务和 reasoning 切换测试，不能只看 changelog。
安全验收：从聊天入口到主机权限
飞书机器人一旦接上本地 Agent，本质上就是把一个聊天入口接到了本机仓库和命令执行环境。安全验收应覆盖：secret 不进入群聊截图；配置文件权限仅服务用户可读；Agent 不运行在拥有全盘敏感文件权限的账号下；危险命令需要审批或被禁止；项目目录与 sibling 项目隔离；日志不打印 app_secret、API key 或用户隐私；群成员变更后 allowlist 会更新；离职用户 open_id 会被移除。
高级场景可用 run_as_user 给 Claude Code 做 OS 用户隔离。它不是容器沙箱，但能利用 UNIX 用户权限限制文件系统可达范围。验收时必须运行 cc-connect doctor user-isolation，证明目标用户不能 sudo、能读写目标 work_dir、不能读取监督用户的秘密文件。对于 Codex 或其他 Agent，如果还未支持同等 run_as_user 隔离，就要通过单独服务账号、文件权限和 Agent 模式补足。
生产测试矩阵
| 验收项 | 测试方法 | 通过标准 |
|---|---|---|
| 安装顺序 | 以服务用户执行 Agent version/login 检查，再启动 cc-connect | Agent 可用，cc-connect 无 CLI not found/auth error |
| Web 命令边界 | 分别执行 cc-connect web 与 cc-connect | 文档确认 web 不启动服务，服务由 cc-connect/daemon 承担 |
| 飞书长连接 | 启动后观察日志与飞书消息 | 连接 WebSocket，无公网 IP，无 webhook URL 依赖 |
| 权限事件 | 核验开放平台权限、事件、卡片回调和发布版本 | im.message.receive_v1 与 card.action.trigger 生效 |
| allow/admin | 允许用户、未允许用户、管理员分别测试 | 入口、群、管理命令边界符合配置 |
| 线程隔离 | 同群两个 reply thread 并行任务 | 上下文、workspace、附件跟随各自 thread |
| 进度语义 | 短任务、长任务、失败任务、权限请求 | ack/reaction/done 含义清晰，无永久处理中 |
| 多图合批 | 手机端连续发送多张截图 | 一个多图 turn，确认在批次主消息上 |
| 空闲 reset | 超过阈值后发新主题 | 自动新会话，旧会话仍可 /list 与 /switch |
| 守护进程 | install/start/status/logs/restart/stop | 重启后自动恢复连接，日志可追踪 |
| Agent 权限 | 只读、编辑、危险命令三类任务 | 审批、拒绝或自动执行符合模式预期 |
| 附件回传 | 发送生成图片和 PDF | 绝对路径文件可回传，超限和禁用有清晰错误 |
| 升级回滚 | 稳定版与 beta 版本分别记录 | 锁定版本、变更理由、回滚命令齐全 |
故障排查优先级
消息没响应时，先看 cc-connect 进程是否在跑，再看飞书 WebSocket 是否连接，再看事件订阅和应用发布，再看 allow_from/allow_chat 是否过滤，再看 Agent 是否认证失败。卡片按钮没反应时，优先查 card.action.trigger 回调订阅和版本发布，而不是重装 Agent。Agent 能在终端跑、飞书里跑不了时，优先检查服务用户环境、PATH、凭据位置和 daemon 环境变量。群里串上下文时，检查 thread_isolation、share_session_in_channel、工作目录切换记录和 idle reset。
升级后出现行为变化时，要把稳定版与预发布版分开复现。v1.5.1-beta.1 的改动覆盖 Feishu、Weixin、Claude Code、Codex、Pi、session、daemon 等多个区域，不能因为一个 Feishu bug 修复就默认所有生产路径都更稳。main 分支继续前进、开放 issue 数量高，也意味着从源码 main 构建时要接受比 release 更多的不确定性。生产环境建议保留旧二进制、旧配置、daemon 卸载/重装命令和 npm/brew/binary 三种安装路径的回滚说明。
接受结论模板
一份合格的生产接受结论应该短而硬：锁定 cc-connect 版本；说明使用 Feishu WebSocket 长连接，不需要公网 IP；说明 Agent 类型是 Codex 还是 Claude Code；列出 allow_from、allow_chat、admin_from 的边界；确认卡片回调、进度卡、ack/reaction/done、多图合批、线程隔离、空闲 reset、daemon、日志和回滚都已演练；记录许可证 caveat；记录未采用 VPS 的原因；记录剩余风险。只有这些都能被实际截图、日志和测试消息支持，cc-connect 才算从“能聊天”进入“可被团队依赖”。
如果只需要个人在飞书里远程操控本机 Claude Code 或 Codex，验收可以轻一些，但边界仍然不能省：cc-connect web 不是服务启动命令，飞书长连接不需要公网入口，admin_from 不能放错层级，稳定版与 beta 版不能混称，README 的 MIT 声明与仓库缺少 LICENSE 文件的事实要同时记录。这些细节看似琐碎，却正是从个人玩具走向生产入口时最容易出事故的地方。