← → 翻页 · B 静态 · ESC 索引
与 AI 协作完成一个项目 · Field Note
PROMPT × CODEX · 26.06 · 01 / 17
HUMAN × AI · HOW I DIRECTED THE BUILD

指挥一台 AI,
造一个真产品

一句话 prompt 起步,三个会话接力,把一个 Telegram 命理 Bot 从零做到上线。这份 pre 讲的不是 bot,是我怎么和 AI 协作把它做出来。
英语提示词课程 · Pre · 周焕
→ 方向键 / 滚轮翻页
钩子 · The Hook
02 / 17
A CONFESSION

我没写过一行排盘算法,
却上线了能算 六种命盘 + AI 解读的 Bot。

所以这份 pre 的主角不是这个 bot——而是我怎么指挥 AI 把它做出来。
成果速览 · What Got Shipped
03 / 17
先看结果 / EVIDENCE FIRST

不是 PPT 里的概念,
是跑得起来的产品

一个由我和 AI 协作完成、真实部署在服务器上的 Telegram 机器人。下面四个数字,都来自真实对话日志。
排盘模式
6种
八字 · 六爻 · 梅花 · 奇门 · 大六壬 · 紫微
开发会话
3个
建 → 上线 → 调优,跨会话接力
服务架构
2服务
Python Bot + Node 引擎侧车
上线产品
1个
长轮询,已在 Telegram 运行
证据 · Running Spec
04 / 17
PRODUCTION · LONG POLLING

不是 demo,
是真的在跑的 bot

命令
13条
排盘模式
6种
Docker 容器
5个
TELEGRAM 命令
/bazi/liuyao/meihua/qimen/daliuren/ziwei/mode/history/settings/forgetme
技术栈
Python 3.12 · aiogram 3
Node 20 · TypeScript 引擎
PostgreSQL ↔ SQLite 降级
Redis ↔ 内存 降级
协作循环 · The Loop
05 / 17
THE COLLABORATION LOOP

每一幕,都在转
同一个循环

01

设定角色 + 给参考

「你是资深架构师…」+「基于 xuanshu 改编」

02

让 AI 出方案

先要 <proposed_plan>,不急着写码

03

我审 + 授权实现

审完才说「PLEASE IMPLEMENT」

04

验证 / 质疑 → 回到 ①

不可用就追问,可疑就让它排查

第一幕 · Act One
06 / 17
ACT 01 · 第一幕

从一句话,
到能跑的
六模式

起点只有一句话 prompt + 一个参考 repo(xuanshu)。我没让 AI 从零空写,而是让它「改造现有资产」。

把「参考别人」,变成「改造成自己的产品」。
REUSE, NOT REWRITE
技法 01 · 角色设定 + 参考锚定
07 / 17
TECHNIQUE 01

开场就把 AI
框成专家

01 我的开场 PROMPT
设定角色
开场就给 AI 定身份、定来源,不让它从零空想。
  • 「你现在是一个资深 Python 架构师、Telegram Bot 工程师…」
  • 「主要基于 xuanshu 项目改编开发」
  • 附上参考稿,先吸收再动手
02 AI 的反应
先核对,再写
它没有立刻写码,而是先摸清现状、做事实核对。
  • 发现 xuanshu 是 Next.js + TS,不是 Python
  • 主动给出两条架构路线让我选
  • 把「改造现有资产」定为基调
技法 02 · 先规划后实现
08 / 17
TECHNIQUE 02

先出方案,
再写一行代码

01AI 出方案<proposed_plan>
02我逐条审确认范围与取舍
03授权实现「PLEASE IMPLEMENT」
04双服务骨架bot + engine
05扩到六模式同一套架构
第一幕 · 成果 / Architecture
09 / 17
ACT 01 · 我们造了什么

我们建的是「产品层」,
算法是站在巨人肩上

LAYER 01
Python Bot 层
Telegram 交互、FSM 多步收参、加密存储、/forgetme 隐私删除。
我们写的
LAYER 02
Node 引擎侧车
契约化适配 6 种排盘 + AI 网关;Zod 校验,返回稳定 JSON。
我们写的
LAYER 03
xuanshu 算法
现成的排盘内核,vendoring 复用——这部分不是我写的。
复用上游
ACT 02 · 第二幕

写出来
≠
跑起来

10 / 17
SHIPPING

真正的考验不是写代码,是把它送上一台 2 核 2G 的服务器,还要让它在墙内连得上 Telegram。

  • 装 Docker、配国内镜像源
  • 起 mihomo 代理穿透出口
  • 填 token、连库、真跑 long-polling
下一幕:我怎么帮 AI 拆掉这些墙
技法 03 · 为 AI 扫清障碍
11 / 17
TECHNIQUE 03

AI 能干活,
环境墙得人来拆

GitHub 加速
gh 前缀拉取源码
npm 镜像
华为云装依赖
pip 镜像
清华 TUNA 源
Docker 镜像源
拉基础镜像
WSL root
wsl --user root
代理订阅
mihomo 出口节点
Bot Token
Telegram 凭据
AI API Key
上游模型网关
8类外部障碍,全由人扫清
0 行代码,但 8 次「递钥匙」——这也是协作的一部分
第三幕 · DEBUG 实录
12 / 17
ACT 03 · 上线之后才是真考验

六个真实 bug,
都靠日志一个个揪出

01
排盘失败 · 400
focus_topic=null,engine 的 Zod 不收 null
02
六爻卦名为空
适配层取错了上游字段名
03
AI 20s 超时
上游实跑 81.7s,bot 提前断开
04
AI 入参过重
整份命盘 15584 字节全塞给了模型
05
历史越聊越卡
单条 4110 字 > 4000 上限
06
满屏 ** 符号
换模型后 Markdown 没转 MarkdownV2
13 / 17 · 高光
TECHNIQUE 05
质疑 AI · CHALLENGE THE ANSWER

上游不可能
这么慢。

— 我没有盲信 AI 给的「超时」诊断
THE REAL CAUSE
根因
  • 让 AI 实测链路:宿主机 1.67s / 容器 2.07s → 网络其实正常
  • 真因:整份命盘 15584 字节 被全量塞给了模型
2153 → 104 字符 · 裁剪后的 AI 入参
质疑 → 排查 → 根因 → 修复
技法 06 · 跨会话交接
14 / 17
TECHNIQUE 06

用一份交接文档,
接力三个会话

每轮结束写一份 HANDOFF.md,下一轮开场先读它——这样跨会话也不丢上下文。

03-26建

① 一句话 prompt → 双服务骨架 → 六模式全部接通

04-05上线

② Docker + mihomo 代理真上线;补齐 case 级 AI 解读

04-05调优

③ 修 5 个真实 bug;AI 改流式输出 + MarkdownV2

开发会话
3个
交接文档
1份
排盘模式
6种
AI 解读
1套
人机分工 · Division of Labor
15 / 17
WHO DID WHAT

我负责判断,
AI 负责实现

人 HUMAN · 我
定方向
想清楚要什么,把不确定性收敛成一个个决定。
  • 定目标、做架构取舍
  • 为环境铺路、递钥匙
  • 质疑结论、验收可用性
AI CODEX
干重活
在我给的方向里,把活儿真正落到代码上。
  • 摸现状、查资料、出方案
  • 写实现、补测试
  • 顺着日志排查 bug
收束 · 6 Principles
16 / 17
TAKEAWAYS · 6 PRINCIPLES

把这次协作,
压成 6 条原则

01
先定角色,再给参考
开场把 AI 框成专家,并锚定改造来源
02
先方案,后实现
先要 <proposed_plan>,审完再授权写码
03
增量交付,控范围
先跑通两模式,再扩六模式、再接 AI
04
主动为 AI 铺路
镜像、权限、代理、密钥,环境墙人来拆
05
不盲信,要质疑
「六个都可用吗」「上游真这么慢?」
06
用交接续命
HANDOFF.md 接力,突破单会话上下文
17 / 17
CLOSING
MANIFESTO

想清楚,
铺好路,
别盲信。

我的工作不是写代码——是想清楚要什么、为 AI 铺好路、再不盲信它给的答案。这就是和 AI 协作的全部。
周焕 · 英语提示词课程
26.06
TAKEAWAYS
03 RULES
01

先方案,后实现

让 AI 先出 <proposed_plan>,审完再说「PLEASE IMPLEMENT」。

02

主动为 AI 铺路

镜像、权限、代理、密钥——环境墙永远得人来拆。

03

不盲信,要质疑

一句「上游不可能这么慢」,揪出了真正的性能根因。

→ 完 · END OF FIELD NOTE
演示 · Live Demo
18 / 18