krisolo/boss
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
3b51641d9922b55402aa45f817081e4e8d8cb39a
boss/prompts/codex_system_full_delivery_master_prompt_cn.md
kris 90cb6b7ff1 feat: ship native boss android console
2026-03-26 23:16:56 +08:00

9.7 KiB
Raw Blame History

Boss 项目完整系统开发总提示词

你当前接手的项目根目录是：

/Users/kris/code/boss

你的任务不是只做分析，也不是只修一个点，而是在当前仓库和现有设计文档约束内，尽可能一次性完成完整系统开发、联调、部署、验证和文档收口，做到“别的 AI 接手时不需要重新摸索项目结构和部署方式”。

你的工作原则：

  • 直接写代码、脚本、配置和文档，不要停留在方案描述。
  • 以仓库当前有效实现为真相，不要把历史材料、空目录、占位目录误判成现成系统。
  • 优先完成当前文档里已经定义的功能，不要自行扩 scope。
  • 除非遇到外部依赖阻塞，否则不要把任务停在“设计完成、待开发”。
  • 每完成一批改动，都要构建、验证、部署或至少做接口检查。
  • 所有关键决策、运行入口、部署方式、阻塞项都必须写回仓库文档，防止上下文压缩后丢失。

1. 先读这些文件

按这个顺序读，读完再动手：

  1. /Users/kris/code/boss/README.md
  2. /Users/kris/code/boss/docs/architecture/ai_handoff_index_cn.md
  3. /Users/kris/code/boss/docs/architecture/repo_map_cn.md
  4. /Users/kris/code/boss/docs/architecture/current_runtime_and_deploy_status_cn.md
  5. /Users/kris/code/boss/docs/architecture/api_and_service_inventory_cn.md
  6. /Users/kris/code/boss/docs/architecture/boss_server_connection_and_deploy_cn.md
  7. /Users/kris/code/boss/docs/architecture/codex_multi_machine_architecture_cn.html
  8. /Users/kris/code/boss/docs/architecture/wechat_project_conversation_mapping_cn.md
  9. /Users/kris/code/boss/docs/architecture/thread_context_budget_and_handoff_protocol_cn.md
  10. /Users/kris/code/boss/docs/architecture/ops_layer_and_repair_protocol_cn.md
  11. /Users/kris/code/boss/docs/architecture/capability_registry_and_audit_protocol_cn.md
  12. /Users/kris/code/boss/docs/architecture/detailed_technical_stack_cn.md
  13. /Users/kris/code/boss/docs/architecture/development_subtasks_and_delivery_plan_cn.md

设计资产位置：

  • Pencil 原稿：/Users/kris/code/boss/design/pencil/codex-ops-mobile-v1.pen
  • 最新导出：/Users/kris/code/boss/design/exports/ui-codex-ops-mobile-v13/

2. 当前有效实现边界

只把这些目录当成当前有效实现：

  • /Users/kris/code/boss/src/app
  • /Users/kris/code/boss/src/components
  • /Users/kris/code/boss/src/lib
  • /Users/kris/code/boss/local-agent
  • /Users/kris/code/boss/deployment
  • /Users/kris/code/boss/scripts
  • /Users/kris/code/boss/docs/architecture
  • /Users/kris/code/boss/prompts

不要把这些目录误当成当前运行系统：

  • /Users/kris/code/boss/docs/source-material
  • /Users/kris/code/boss/deploy
  • /Users/kris/code/boss/src/boss_control
  • /Users/kris/code/boss/src/boss_device_agent

3. 你的最终目标

在不偏离现有产品定义的前提下，把 Boss 项目收口成一个“当前范围内功能尽量齐全、可运行、可部署、可验证、可移交”的系统。

这里的“功能尽量齐全”至少包括：

A. Web / App 壳层

  • 微信式一级导航：会话 / 设备 / 我的
  • 登录、注册、忘记密码、验证码流程
  • 会话首页：主 Agent 置顶、项目会话列表、设备头像/群头像、时间、置顶状态、上下文余量圆环
  • 项目聊天页：聊天流、语音/图片/视频/转发入口、项目目标、版本迭代记录
  • 项目目标页：圆形完成标记、完成自动划线、支持编辑、主 Agent 复核逻辑
  • 版本迭代记录页：只读，由主 Agent 汇总
  • 设备页：设备状态、账号、项目、5h/7d 额度、设备管理入口
  • 我的页：头像、账号、唯一二维码、账号与安全、设置、关于、OTA、运维与修复
  • 我的 > 运维与修复 > 运维对话 / 审计对话

B. 服务端 / API

  • 当前页面需要的 API 全部打通
  • 设备心跳和设备状态更新打通
  • 项目目标编辑、完成态切换打通
  • 登录/注册/忘记密码/验证码打通
  • 适当补足当前缺失但被 UI/业务逻辑依赖的接口
  • 统一健康检查接口

C. 设备端

  • local-agent 可独立运行
  • 设备端可上报：设备标识、账号、项目列表、状态、5h/7d 额度
  • 本地健康检查存在
  • 本地常驻方案存在

D. 部署与运维

  • 本地运行命令明确
  • 服务器部署命令明确
  • systemd、Caddy、launchd 配置正确
  • 部署脚本可直接用
  • HTTPS 自动续签链路保留
  • 当前公网域名状态和阻塞要写清楚

E. 文档与交接

  • 所有实际入口都写进 README
  • 所有关键部署、验证、恢复方式都写进文档
  • 交接文档与当前实现保持一致
  • 不允许代码和文档严重脱节

4. 技术约束

当前必须遵守这些约束：

  • Web 使用 Next.js App Router
  • 当前实际持久化是轻量文件存储：/Users/kris/code/boss/data/boss-state.json
  • 当前不要默认引入 PostgreSQL、Redis、NATS 等更重基础设施，除非确有必要且你能完成迁移与验证
  • 当前路线是“极轻云 + 本地设备端”
  • 服务器固定为：
    • Host: 106.53.170.158
    • User: ubuntu
    • Domain: boss.hyzq.net
  • 服务器连接优先使用 skill：
    • /Users/kris/.codex/skills/boss-server-debug/SKILL.md

如果你需要连服务器，优先用：

"$HOME/.codex/skills/boss-server-debug/scripts/server_ssh.sh" health
"$HOME/.codex/skills/boss-server-debug/scripts/server_ssh.sh" exec "systemctl status boss-web --no-pager"
"$HOME/.codex/skills/boss-server-debug/scripts/server_ssh.sh" login

如果你需要重新部署，优先用：

cd /Users/kris/code/boss
./scripts/deploy-server.sh

5. 真实状态提醒

你不能沿用旧上下文里可能已经过期的结论。以当前仓库文档和现场验证为准。

当前需要特别注意：

  • 服务器端 Caddy 已经拿到过 boss.hyzq.net 证书
  • 但当前本机网络下，boss.hyzq.net 的公网解析和 HTTPS 访问仍要再次复核
  • 所以你不能直接假设公网 HTTPS 已完全稳定可用

同样要注意：

  • 当前验证码还是 MVP 级别，默认直接回显
  • 当前认证不等于正式生产级账号体系
  • 当前设备接入与项目扫描仍是 MVP 能力，不是最终形态

6. 你必须执行的开发流程

按下面顺序推进，不要跳：

第一步：审计现状

  • 核对仓库结构
  • 核对当前路由和 API
  • 核对当前本地运行方式
  • 核对当前服务器运行状态
  • 明确哪些功能已经有，哪些只是文档定义还没落地

第二步：补齐功能

  • 先补齐已经定义但未完成的 UI、API、数据、设备端逻辑
  • 优先消除“页面有入口但没有真实逻辑”的地方
  • 优先消除“文档说有，但代码里没有”的地方

第三步：回归验证

每完成一批改动，都至少做这些检查：

cd /Users/kris/code/boss
npm run lint
npm run build
curl -sS http://127.0.0.1:3000/api/health
curl -sS http://127.0.0.1:4317/health

如果改了服务器部署链路，再做：

cd /Users/kris/code/boss
./scripts/deploy-server.sh
"$HOME/.codex/skills/boss-server-debug/scripts/server_ssh.sh" exec "curl -sS http://127.0.0.1:3000/api/health"

第四步：同步文档

每完成一块重要功能，至少同步更新：

  • README.md
  • docs/architecture/current_runtime_and_deploy_status_cn.md
  • docs/architecture/api_and_service_inventory_cn.md

如果你调整了项目结构，也同步更新：

  • docs/architecture/repo_map_cn.md
  • docs/architecture/ai_handoff_index_cn.md

第五步：最终交付

交付时必须给出：

  • 代码改动摘要
  • 本地运行命令
  • 本地常驻方式
  • 服务器部署命令
  • 服务器当前状态
  • 域名 / HTTPS 当前状态
  • 仍未完成的外部依赖
  • 建议下一个 AI 线程接手的优先事项

7. 功能完成判断标准

只有同时满足下面这些，才算“这一轮尽量收完了”：

  • 代码存在，不只是文档存在
  • 页面存在，不只是路由存在
  • 入口存在，且点击后有真实逻辑
  • API 存在，且能被页面或 agent 真正调用
  • 本地可构建
  • 本地可运行
  • 服务器可部署
  • 文档已同步

如果你遇到外部阻塞，例如：

  • DNS 不可控
  • 短信/邮件服务未接
  • 真实设备不在线

那你要：

  1. 把可控部分先实现完
  2. 把不可控部分做成可替换或可演示的 MVP
  3. 在文档里明确写出阻塞点和下一步接法

8. 当前最重要的协作逻辑

这个系统里最关键的不是单页 UI，而是主 Agent 对线程上下文预算的监管。

你必须保住这条逻辑：

  • 每个线程都要有剩余上下文预算表示
  • UI 里的圆环和设备端/服务端的数据语义必须一致
  • 主 Agent 必须基于线程余量决定哪些任务必须在背景信息压缩前完成
  • 进入压缩前临界区时，要优先做摘要、handoff、结论固化和关键结果落库

这部分逻辑不能被你在开发中弱化或删掉。

9. 不要做的事

  • 不要删已有设计资产
  • 不要把整个系统重写成完全不同的技术路线
  • 不要在没有验证的情况下声称 HTTPS 已彻底闭环
  • 不要只改页面不改 API
  • 不要只改代码不改文档
  • 不要把“后续再做”当成本轮默认结束条件

10. 你完成后应该输出什么

最后请直接输出：

  1. 本轮完成了哪些功能
  2. 哪些文档已同步
  3. 本地如何启动
  4. 本地 agent 如何启动
  5. 服务器如何部署
  6. 服务器当前是否健康
  7. 域名和 HTTPS 当前实际状态
  8. 还有哪些外部阻塞
  9. 下一线程最适合继续做哪 3 件事

不要只给总结，要给可执行命令和真实文件路径。