gavindiaz/vibe-coding-cn
1
0
Fork 0
mirror of https://github.com/tradecatlabs/vibe-coding-cn.git synced 2026-08-01 13:17:45 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: docs - remove case studies

Browse Source
This commit is contained in:
tukuaiai
2026-05-02 04:33:07 +08:00
parent d0a361e22c
commit 1b3fe53d8b
32 changed files with 44 additions and 1694 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/ISSUE_TEMPLATE/documentation.md
+1 -2
View File
@@ -34,9 +34,8 @@ body:
options:
- "README 主页"
- "Wiki"
- "实战案例"
- "教程与指南"
- "方法论与原则"
- "其他"
validations:
required: true
required: true
.github/labeler.yml
-5
View File
@@ -29,11 +29,6 @@ prompt:
- changed-files:
- any-glob-to-any-file: 'prompts/**/*.md'
# 实战案例相关的标签
example:
- changed-files:
- any-glob-to-any-file: 'docs/case-studies/**/*.md'
# 外部工具/依赖相关的标签
repos:
- changed-files:
AGENTS.md
+1 -2
View File
@@ -154,7 +154,6 @@ git push origin develop
│ ├── guides/ # 操作指南预留区
│ ├── playbooks/ # 可复用流程、工具方法与工作流
│ ├── references/ # 清单、约束、常见坑、审查标准
│ ├── case-studies/ # 实战案例与问题记录
│ └── faq.md # 高频问题
│
├── prompts/ # 提示词库入口（指向云端表格）
@@ -314,7 +313,7 @@ bash scripts/backups/一键备份.sh
### Core Directories
- **`prompts/`**: 提示词库入口（指向云端表格）
- **`skills/`**: 扁平化技能库（详见 skills/README.md）
- **`docs/`**: 知识库（principles、guides、case-studies）
- **`docs/`**: 知识库（getting-started、concepts、guides、playbooks、references）
- **`assets/`**: 外部资源（在线表格）入口与使用说明
- **`tools/prompts-library/`**: Excel ↔ Markdown 转换工具
- **`tools/chat-vault/`**: AI 聊天记录保存工具
CHANGELOG.md
+1
View File
@@ -13,3 +13,4 @@
- 清退 `tools/chat-vault/monitoring/grafana/monitor-tui/` 中误提交的第三方 btop 源码镜像，降低仓库噪音与语言统计污染。
- 创建 `baseline-skill-cleanup-20260502-041941` 基线标签，开始清理领域型/工具型 Skills。
- 清退 `ccxt`、`claude-code-guide`、`claude-cookbooks`、`coingecko`、`cryptofeed`、`ddd-doc-steward`、`headless-cli`、`hummingbot`、`markdown-to-epub`、`polymarket`、`postgresql`、`proxychains`、`snapdom`、`sop-generator`、`telegram-dev`、`timescaledb`、`tmux-autopilot`、`twscrape` 等 Skill 目录，仅保留 `auto-skill` 与 Claude 官方 skills 软链接入口。
- 清退 `docs/case-studies/` 实战案例目录，并同步更新 docs 索引、目录级 AGENTS、metadata、labeler 和相关 README 链接口径。
README.md
+15 -38
View File
@@ -456,43 +456,20 @@ pip install -r tools/prompts-library/scripts/requirements.txt
├── CONTRIBUTING.md # 贡献指南
├── .gitignore # Git 忽略规则
│
├── assets/ # 外部资源（指向在线表格）
│ ├── README.md # 远程表格索引（唯一真相源）
│ ├── AGENTS.md # assets/ 目录规则
│ ├── config/ # 工具与开发配置
│ │ └── .codex/ # Codex CLI 配置（项目级）
│ │ ├── config.toml # Codex CLI 配置文件
│ │ └── AGENTS.md # Codex/Agent 指南（本目录）
│ ├── documents/ # 文档库
│ │ ├── principles/ # 原则与思想（fundamentals + philosophy）
│ │ │ ├── fundamentals/ # 基础原则、问题求解、工程范式与代码质量
│ │ │ └── philosophy/ # 原 05-哲学与方法论
│ │ ├── guides/ # 入门与方法（getting-started + playbook）
│ │ │ ├── getting-started/ # 原 01-入门指南
│ │ │ └── playbook/ # 原 02-方法论
│ │ ├── case-studies/ # 原 03-实战
│ │ └── workflow/ # 工作流模板
│ ├── prompt/ # 提示词库（指向云端表格）
│ │ ├── README.md # 在线表格链接
│ │ └── AGENTS.md # prompt/ 目录规则
│ ├── skills/ # 技能库（扁平化）
│ │ ├── README.md # skills 总览与索引
│ │ ├── AGENTS.md # skills/ 目录规则
│ │ ├── auto-skill/ # 元技能核心
│ │ └── claude-official-skills/ # Claude 官方 skills 软链接入口
│ └── repos/ # 外部工具与依赖镜像（含 Git submodule）
│ ├── README.md # 外部工具索引
│ ├── prompts-library/ # Excel ↔ Markdown 互转工具，含内部 JSONL Excel 拆分导出
│ ├── chat-vault/ # AI 聊天记录保存工具
│ ├── Skill_Seekers-development/ # Skills 制作器 (submodule)
│ ├── html-tools-main/ # HTML 工具集
│ ├── my-nvim/ # Neovim 配置
│ ├── MCPlayerTransfer/ # MC 玩家迁移工具
│ ├── XHS-image-to-PDF-conversion/ # 小红书图片转 PDF
│ ├── backups/ # 历史备份脚本快照
│ ├── .tmux/ # oh-my-tmux (submodule)
│ ├── tmux/ # tmux 源码 (submodule)
│ └── claude-official-skills/ # Claude 官方 skills (submodule)
├── docs/ # 核心知识库
│ ├── getting-started/ # 从零开始、学习地图、环境与 AI CLI 配置
│ ├── concepts/ # 核心概念、方法论与底层模型
│ ├── guides/ # 操作指南
│ ├── playbooks/ # 可复用流程、工具方法与工作流
│ └── references/ # 清单、约束、常见坑、审查标准
├── prompts/ # 提示词库入口（指向云端表格）
├── skills/ # 技能库入口
│ ├── auto-skill/ # 元技能核心
│ └── claude-official-skills/ # Claude 官方 skills 软链接入口
├── tools/ # 辅助工具、外部仓库与工具配置
├── scripts/ # 自动化脚本
├── metadata/ # 机器可读索引与 AI 引用资产
├── assets/ # 静态资产与外部资源入口
│
├── .github/ # GitHub 配置
│ ├── workflows/ # CI/CD 工作流
@@ -531,7 +508,7 @@ prompts/
skills/
README.md # skills 总览与索引
docs/
principles/fundamentals/*, principles/philosophy/*, guides/*, case-studies/* 等知识库
getting-started/*, concepts/*, guides/*, playbooks/*, references/* 等知识库
assets/
README.md # 外部资源（在线表格）唯一真相源入口
scripts/backups/
docs/AGENTS.md
+25 -24
View File
@@ -2,44 +2,45 @@
## 目录用途
`docs/` 存放项目知识库文档，包含方法论、入门指南、实战案例等。
`docs/` 存放项目核心知识库文档，包含入门路径、核心概念、操作指南、可复用流程与参考清单。
## 目录结构
```
```text
docs/
├── principles/ # 原则与思想（fundamentals + philosophy）
│ ├── fundamentals/ # 基础原则、问题求解、工程范式与代码质量
│ └── philosophy/ # 原 05-哲学与方法论
├── guides/ # 入门与方法（getting-started + playbook）
│ ├── getting-started/ # 原 01-入门指南
│ └── playbook/ # 原 02-方法论
├── case-studies/ # 原 03-实战
└── workflow/ # 可复用工作流模板
├── README.md # 知识库总索引
├── getting-started/ # 从零开始、学习地图、环境与 AI CLI 配置
├── concepts/ # 核心概念、方法论与底层模型
├── guides/ # 操作型指南
├── playbooks/ # 可复用流程、工具方法与工作流
├── references/ # 清单、约束、常见坑、审查标准
└── faq.md # 高频问题
```
## 关键入口
- `guides/getting-started/README.md`：零基础学习路径索引。
- `guides/getting-started/Vibe Coding 经验.md`：语言化、门禁、人机分工与 Vibe Coding 工程闭环。
- `guides/getting-started/Codex-CLI配置.md`：默认 AI CLI 路线。
- `guides/getting-started/OpenCode-CLI配置.md`：Codex CLI 不可用时的备选路线。
- `principles/fundamentals/拼好码.md`：胶水编程的超集，覆盖复用优先、能力编排、边界治理与工程门禁。
- `README.md`：知识库总索引。
- `getting-started/学习地图.md`：按目标选择学习路径。
- `getting-started/Vibe Coding 经验.md`：语言化、门禁、人机分工与 Vibe Coding 工程闭环。
- `getting-started/Codex-CLI配置.md`：默认 AI CLI 路线。
- `concepts/拼好码.md`：复用优先、能力编排、边界治理与工程门禁。
- `guides/仓库维护与质量门禁.md`：仓库维护、迁移检查和质量门禁指南。
## 操作规范
### 允许
- 新增/修改文档内容
- 修复错误和过时信息
- 添加新的实战案例
- 为每个一级目录维护 `README.md` 作为索引入口（如存在）
- 新增/修改文档内容。
- 修复错误和过时信息。
- 为每个一级目录维护 `README.md` 作为索引入口（如存在）。
### 禁止
- 删除现有文档（除非明确要求）
- 大规模重命名/移动文件导致链接失效（如必须调整，需同步更新引用）
- 删除现有文档（除非明确要求）。
- 大规模重命名/移动文件导致链接失效（如必须调整，需同步更新引用）。
## 命名规范
- 文件名使用中文
- 使用 Markdown 格式
- 目录名使用简短英文（便于跨平台与链接稳定）
- 文件名使用中文或清晰英文。
- 使用 Markdown 格式。
- 目录名使用简短英文，保证跨平台与链接稳定。
docs/README.md
+1 -2
View File
@@ -1,6 +1,6 @@
# 知识库总索引
> `docs/` 是本仓库的核心知识库入口，承载从入门路径、核心概念、操作指南、可复用流程、参考清单到实战案例的全部文档。
> `docs/` 是本仓库的核心知识库入口，承载从入门路径、核心概念、操作指南、可复用流程到参考清单的全部文档。
## 目录结构
@@ -11,7 +11,6 @@
| [guides](./guides/) | 操作型指南 |
| [playbooks](./playbooks/) | 可复用流程、工具使用方法与工作流 |
| [references](./references/) | 清单、模板、强约束、常见坑与审查标准 |
| [case-studies](./case-studies/) | 实战案例与问题记录 |
| [faq.md](./faq.md) | 高频问题 |
## 推荐入口
docs/case-studies/README.md
-18
View File
@@ -1,18 +0,0 @@
# 🎯 实战
> 真实项目的开发经验与复盘
## 🏗️ 项目实战经验
| 项目 | 说明 |
|:---|:---|
| [fate-engine-dev](fate-engine-dev) | Fate Engine 开发记录 |
| [openclaw-dev](openclaw-dev) | OpenClaw 架构 / 部署 / 生态调研资料 |
| [polymarket-dev](polymarket-dev) | Polymarket 数据分析 |
| [telegram-dev](telegram-dev) | Telegram Bot 开发 |
## 🔗 相关资源
- [基础指南](../references) - 核心理念与方法论
- [入门指南](../getting-started) - 环境配置
- [方法论](../playbooks) - 工具与经验
- [外部资源（在线表格）](../../README.md) - 外部资源唯一真相源入口
docs/case-studies/fate-engine-dev/ascii可视化-prompt.md
-1
View File
@@ -1 +0,0 @@
# 任务说明：指定项目仓库的系统分析与可视化建模## 角色设定你是一名 **资深软件架构师 / 系统分析专家**，具备从实际代码仓库中进行架构逆向分析、系统抽象与技术文档生成的能力。## 分析对象- **分析对象不是预设的“微服务系统”概念**- 分析对象为：**我指定的项目代码仓库**- 项目形态可能包括（但不限于）： - 单体应用 - 微服务架构 - 模块化系统 - 混合架构（单体 + 服务化）- 你需要基于 **真实仓库结构与代码事实** 判断其架构形态，而不是先验假设## 总体目标对该 **指定项目仓库** 进行系统级分析，并生成 **基于 ASCII 字符渲染的可视化图表**，用于理解系统结构与运行流程。## 分析任务要求### 1. 系统与架构识别- 从仓库中识别： - 模块 / 服务 / 子系统边界 - 各组件的核心职责- 判断并说明： - 架构风格（如单体、微服务、分层架构、事件驱动等） - 组件之间的依赖关系与调用方式- 不对架构类型作任何未经证据支持的假设### 2. 关键流程分析- 选取 **具有代表性的核心业务流程或系统主流程**- 明确： - 调用起点与终点 - 中间参与的模块 / 服务 /组件 - 同步与异步交互关系（若存在）## 可视化产出要求（ASCII）### 3. 序列图（Sequence Diagram）- 基于实际代码与调用关系绘制- 展示： - 调用顺序 - 请求 / 响应方向 - 参与的模块、服务或组件- 使用 **纯 ASCII 字符**- 保证在等宽字体环境下对齐、可读- 不引入任何外部绘图语法（如 Mermaid、PlantUML）### 4. 系统结构图（System / Architecture Diagram）- 从整体视角展示系统组成： - 模块 / 服务 - 外部依赖（如数据库、消息队列、第三方 API） - 基础设施组件（如有）- 明确逻辑分层或物理边界（若可识别）- 使用 **纯 ASCII 字符**，强调结构与关系的清晰性## 文件输出规范- 序列图与系统图 **必须分别独立输出为文件**- 保存位置：**项目根目录**- 推荐文件名（可根据项目实际调整）： - `sequence_diagram.txt` - `system_architecture.txt`- 每个文件中 **只包含对应的 ASCII 图表内容**- 不在文件中混入解释性说明文字## 表达与风格要求- 使用 **专业、严谨的技术文档语言**- 描述基于代码事实，不进行推测性扩展- 若存在信息不足之处，需明确标注为： -「基于当前仓库可见信息的假设」## 约束条件- 禁止使用图片、截图或富文本图形- 禁止使用 Markdown 图表或任何非 ASCII 表达- 所有图表必须可直接保存、可长期维护、可用于代码仓库## 最终目标输出一套 **严格基于指定项目仓库的系统级 ASCII 可视化成果**，用于帮助开发者、审阅者或维护者快速、准确地理解该项目的结构与运行逻辑。
docs/case-studies/fate-engine-dev/prompt-system-bazi-kline.md
-46
View File
@@ -1,46 +0,0 @@
# 人生K线 LLM 系统提示词（完整原文）
以下内容整理自外部项目 `lifekline-main` 的 `BAZI_SYSTEM_INSTRUCTION` 字符串（该外部项目源码当前不随本仓库分发），已原样展开，便于单独查看与复用。
```
你是一位八字命理大师，精通加密货币市场周期。根据用户提供的四柱干支和大运信息，生成"人生K线图"数据和命理报告。
**核心规则:**
1. **年龄计算**: 采用虚岁，从 1 岁开始。
2. **K线详批**: 每年每月的 `reason` 字段必须**控制在40-60字以内**，简洁描述吉凶趋势即可。
3. **评分机制**: 所有维度给出 0-10 分。
4. **数据起伏**: 让评分根据真实的测算波动
**输出JSON结构:**
{
"bazi": ["年柱", "月柱", "日柱", "时柱"],
"summary": "命理总评（100字）",
"summaryScore": 8,
"personality": "性格分析（80字）",
"personalityScore": 8,
"industry": "事业分析（80字）",
"industryScore": 7,
"fengShui": "风水建议：方位、地理环境、开运建议（80字）",
"fengShuiScore": 8,
"wealth": "财富分析（80字）",
"wealthScore": 9,
"marriage": "婚姻分析（80字）",
"marriageScore": 6,
"health": "健康分析（60字）",
"healthScore": 5,
"family": "六亲分析（60字）",
"familyScore": 7,
"crypto": "币圈分析（60字）",
"cryptoScore": 8,
"chartPoints": [
{"age":1,"year":1990,"daYun":"童限","ganZhi":"庚午","open":50,"close":55,"high":60,"low":45,"score":55,"reason":"开局平稳，家庭呵护"},
... (共x条（x = 全部流月数量），reason控制在40-60字)
]
}
```
# 使用说明
- 作为 `system` 消息传入 `/chat/completions`，禁止模型输出 Markdown 代码块（由 `geminiService` 再次强调）。
- 保证 共x条（x = 全部流月数量） 条 `chartPoints`，并严格执行 `reason` 字数与评分波动要求。
docs/case-studies/fate-engine-dev/prompt-user-bazi-kline.md
-53
View File
@@ -1,53 +0,0 @@
# 人生K线 LLM 用户提示词模板（完整原文）
本文件整理自外部项目 `lifekline-main` 的 `userPrompt` 拼装逻辑（该外部项目源码当前不随本仓库分发），已替换为模板变量，便于直接复用。
```
请根据以下**已经排好的**八字四柱和**指定的大运信息**进行分析。
【基本信息】
性别：${genderStr}
姓名：${input.name || "未提供"}
出生年份：${input.birthYear}年 (阳历)
【八字四柱】
年柱：${input.yearPillar} (天干属性：${yearStemPolarity === 'YANG' ? '阳' : '阴'})
月柱：${input.monthPillar}
日柱：${input.dayPillar}
时柱：${input.hourPillar}
【大运核心参数】
1. 起运年龄：${input.startAge} 岁 (虚岁)。
2. 第一步大运：${input.firstDaYun}。
3. **排序方向**：${daYunDirectionStr}。
【必须执行的算法 - 大运序列生成】
请严格按照以下步骤生成数据：
1. **锁定第一步**：确认【${input.firstDaYun}】为第一步大运。
2. **计算序列**：根据六十甲子顺序和方向（${daYunDirectionStr}），推算出接下来的 9 步大运。
${directionExample}
3. **填充 JSON**：
- Age 1 到 ${startAgeInt - 1}: daYun = "童限"
- Age ${startAgeInt} 到 ${startAgeInt + 9}: daYun = [第1步大运: ${input.firstDaYun}]
- Age ${startAgeInt + 10} 到 ${startAgeInt + 19}: daYun = [第2步大运]
- Age ${startAgeInt + 20} 到 ${startAgeInt + 29}: daYun = [第3步大运]
- ...以此类推直到 100 岁。
【特别警告】
- **daYun 字段**：必须填大运干支（10年一变），**绝对不要**填流年干支。
- **ganZhi 字段**：填入该年份的**流年干支**（每年一变，例如 2024=甲辰，2025=乙巳）。
任务：
1. 确认格局与喜忌。
2. 生成 **1-100 岁 (虚岁)** 的人生流年K线数据。
3. 在 `reason` 字段中提供流年详批。
4. 生成带评分的命理分析报告（包含性格分析、币圈交易分析、发展风水分析）。
请严格按照系统指令生成 JSON 数据。
```
# 使用说明
- 作为 `user` 消息传入 `/chat/completions`，与系统提示词配套使用。
- 变量含义：`genderStr` 由性别+乾坤文字组成；`startAgeInt` 为起运年龄整数；`directionExample` 随顺/逆行变化；其余变量直接取用户输入或排盘结果。
- 输出需为纯 JSON，`geminiService` 会自动剥离代码块并校验 `chartPoints`。
docs/case-studies/fate-engine-dev/完整性检查-prompt.md
-1
View File
@@ -1 +0,0 @@
"# 系统性代码与功能完整性检查提示词（优化版）## 角色设定你是一名**资深系统架构师与代码审计专家**，具备对生产级 Python 项目进行深度静态与逻辑审查的能力。## 核心目标对当前代码与工程结构进行**系统性、全面、可验证的检查**，确认以下所有条件均被严格满足，不允许任何形式的功能弱化、裁剪或替代实现。---## 检查范围与要求### 一、功能完整性验证- 确认**所有功能模块均为完整实现** - 不存在： - 阉割逻辑 - Mock / Stub 替代 - Demo 级或简化实现- 确保行为与**生产环境成熟版本**完全一致---### 二、代码复用与集成一致性- 验证是否： - **100% 复用既有成熟代码** - 未发生任何形式的重新实现或功能折叠- 确认当前工程是**直接集成**，而非复制后修改的版本---### 三、本地库调用真实性检查重点核查以下导入链路是否真实、完整、生效：pythonsys.path.append('/home/lenovo/.projects/fate-engine/libs/external/github/*')from datas import * # 必须为完整数据模块from sizi import summarys # 必须为完整算法实现要求：* `sys.path` 引入路径真实存在且指向**生产级本地库*** `datas` 模块： * 包含全部数据结构、接口与实现 * 非裁剪版 / 非子集* `sizi.summarys`： * 为完整算法逻辑 * 不允许降级、参数简化或逻辑跳过---### 四、导入与执行有效性* 确认： * 所有导入模块在运行期**真实参与执行** * 不存在“只导入不用”“接口空实现”等伪集成情况* 检查是否存在： * 路径遮蔽（shadowing） * 重名模块误导加载 * 隐式 fallback 到简化版本---## 输出要求请以**审计报告**形式输出，至少包含：1. 检查结论（是否完全符合生产级完整性）2. 每一项检查的明确判断（通过 / 不通过）3. 若存在问题，指出： * 具体模块 * 风险等级 * 可能造成的后果**禁止模糊判断与主观推测，所有结论必须基于可验证的代码与路径分析。**"
docs/case-studies/fate-engine-dev/胶水开发要求-prompt.md
-1
View File
@@ -1 +0,0 @@
# 胶水开发要求（强依赖复用 / 生产级库直连模式）## 角色设定你是一名**资深软件架构师与高级工程开发者**，擅长在复杂系统中通过强依赖复用成熟代码来构建稳定、可维护的工程。## 总体开发原则本项目采用**强依赖复用的开发模式**。核心目标是： **尽可能减少自行实现的底层与通用逻辑，优先、直接、完整地复用既有成熟仓库与库代码，仅在必要时编写最小业务层与调度代码。**---## 依赖与仓库使用要求### 一、依赖来源与形式- 允许并支持以下依赖集成方式： - 本地源码直连（`sys.path` / 本地路径） - 包管理器安装（`pip` / `conda` / editable install）- 无论采用哪种方式，**实际加载与执行的必须是完整、生产级实现**，而非简化、裁剪或替代版本。---### 二、强制依赖路径与导入规范在代码中，必须遵循以下依赖结构与导入形式（示例）：```pythonsys.path.append('/home/lenovo/.projects/fate-engine/libs/external/github/*')from datas import * # 完整数据模块，禁止子集封装from sizi import summarys # 完整算法实现，禁止简化逻辑```要求：* 指定路径必须真实存在并指向**完整仓库源码*** 禁止复制代码到当前项目后再修改使用* 禁止对依赖模块进行功能裁剪、逻辑重写或降级封装---## 功能与实现约束### 三、功能完整性约束* 所有被调用的能力必须来自依赖库的**真实实现*** 不允许： * Mock / Stub * Demo / 示例代码替代 * “先占位、后实现”的空逻辑* 若依赖库已提供功能，**禁止自行重写同类逻辑**---### 四、当前项目的职责边界当前项目仅允许承担以下角色：* 业务流程编排（Orchestration）* 模块组合与调度* 参数配置与调用组织* 输入输出适配（不改变核心语义）明确禁止：* 重复实现算法* 重写已有数据结构* 将复杂逻辑从依赖库中“拆出来自己写”---## 工程一致性与可验证性### 五、执行与可验证要求* 所有导入模块必须在运行期真实参与执行* 禁止“只导入不用”的伪集成* 禁止因路径遮蔽、重名模块导致加载到非目标实现---## 输出要求（对 AI 的约束）在生成代码时，你必须：1. 明确标注哪些功能来自外部依赖2. 不生成依赖库内部的实现代码3. 仅生成最小必要的胶水代码与业务逻辑4. 假设依赖库是权威且不可修改的黑箱实现**本项目评价标准不是“写了多少代码”，而是“是否正确、完整地站在成熟系统之上构建新系统”。**你需要处理的是：
docs/case-studies/fate-engine-dev/问题描述-prompt.md
-1
View File
@@ -1 +0,0 @@
# 任务说明（System Prompt）你是一名**高级软件架构顾问与技术问题分析专家**。 你的任务是：**对当前代码项目中遇到的问题进行系统性、结构化、可诊断的完整描述**，以便后续进行高质量的技术分析、调试、重构或方案设计。---## 输出目标请基于我提供的信息，**完整、清晰、无歧义地整理并呈现项目现状**，确保任何第三方技术人员或大型语言模型都可以在**无需额外追问**的情况下理解问题全貌。---## 输出内容结构（必须严格遵循）请按照以下固定结构输出内容：### 1. 项目背景（Background）- 项目整体目标与业务场景- 项目当前所处阶段（开发中 / 测试中 / 生产环境 / 重构阶段等）- 该问题在项目中的重要性与影响范围### 2. 技术上下文（Technical Context）- 使用的编程语言、框架、运行环境- 架构形态（单体 / 微服务 / 前后端分离 / 本地 + 云等）- 相关依赖、第三方服务或基础设施（如数据库、消息队列、API、云服务）### 3. 核心问题描述（Problem Description）- 问题的**具体表现**（错误信息、异常行为、性能问题、逻辑错误等）- 问题出现的**触发条件**- 预期行为 vs 实际行为（对比说明）- 是否具备稳定复现路径### 4. 相关实体（Entities）- 涉及的核心模块 / 类 / 函数 / 文件- 关键数据结构或业务对象- 相关角色（如用户、服务、进程、线程等）### 5. 相关链接与参考资料（References）- 代码仓库链接（如 GitHub / GitLab）- 相关 issue、PR、文档或设计说明- 外部参考资料（API 文档、官方说明、技术文章等）### 6. 功能与目的（Function & Intent）- 该代码或模块原本设计要实现的功能- 当前问题阻碍或偏离了哪些目标- 从业务与技术角度说明“为什么这个问题必须被解决”---## 表达与格式要求- 使用**技术性、客观、精确**的语言，避免情绪化或模糊表述 - 尽量使用**条列（bullet points）与短段落**，避免大段散文 - 不要提出解决方案，只做**问题与上下文的完整建模**- 不要省略你认为“显而易见”的信息，假设读者**对项目完全陌生**---## 最终目标你的输出将作为：- 技术问题分析输入- Debug / 架构评审 / AI 辅助分析的上下文- 后续自动化推理或方案生成的**唯一事实来源**请严格按照上述结构与要求输出。
docs/case-studies/openclaw-dev/OpenClaw 橙皮书 - AI进化论花生.md
-1203
View File
File diff suppressed because it is too large Load Diff
docs/case-studies/openclaw-dev/README.md
-8
View File
@@ -1,8 +0,0 @@
# OpenClaw 实战资料
> OpenClaw（开源自托管 AI Agent 系统）相关的调研、架构与部署一站式资料归档。
## 文档
- `OpenClaw 橙皮书 - AI进化论花生.md`：从入门到精通的参考手册（架构、部署、渠道接入、Skills、模型配置、安全与成本）。
docs/case-studies/polymarket-dev/POLYMARKET_LINK_FORMAT.md
-99
View File
@@ -1,99 +0,0 @@
# Polymarket 链接格式规范
## 问题描述
生成的 Polymarket 链接返回 "Oops...we didn't forecast this" 错误页面，即使 HTTP 状态码是 200。
## 根本原因
Polymarket API 返回两种不同的 slug：
| 字段 | 名称 | 用途 |
|------|------|------|
| `slug` | Market Slug | 市场标识，**不能用于 URL** |
| `events[0].slug` | Event Slug | 事件标识，**必须用于 URL** |
### 示例对比
```
市场: "Lighter market cap (FDV) >$1B one day after launch?"
API 返回:
slug: "lighter-market-cap-fdv-1b-one-day-after-launch" ❌ 错误
events[0].slug: "lighter-market-cap-fdv-one-day-after-launch" ✅ 正确
错误链接: https://polymarket.com/event/lighter-market-cap-fdv-1b-one-day-after-launch
正确链接: https://polymarket.com/event/lighter-market-cap-fdv-one-day-after-launch
```
注意差异：market slug 包含 `-1b-`，event slug 不包含。
## 为什么 HTTP 200 但页面报错？
Polymarket 前端是 SPA（单页应用）：
- 所有 `/event/*` 路径都返回 HTTP 200（返回 HTML 壳）
- 前端 JS 加载后再请求数据
- 如果 slug 无效，前端显示 "Oops" 错误
**结论：HTTP 状态码无法验证链接有效性。**
## 正确的链接生成方式
```javascript
// ✅ 正确
const getLink = (market) => {
const events = market.events || [];
const slug = events[0]?.slug || market.slug; // 优先用 event slug
return `https://polymarket.com/event/${slug}`;
};
// ❌ 错误
const getLink = (market) => {
return `https://polymarket.com/event/${market.slug}`;
};
```
## API 响应结构
```json
{
"question": "Lighter market cap (FDV) >$1B one day after launch?",
"slug": "lighter-market-cap-fdv-1b-one-day-after-launch",
"events": [
{
"slug": "lighter-market-cap-fdv-one-day-after-launch",
"title": "Lighter Market Cap (FDV) One Day After Launch"
}
]
}
```
## 验证方法
不能只检查 HTTP 状态码，需要：
```bash
# 方法1：检查页面内容是否包含错误
curl -s "https://polymarket.com/event/xxx" | grep -q "didn't forecast" && echo "无效"
# 方法2：对比 API 返回的 slug
curl -s "https://gamma-api.polymarket.com/markets?slug=xxx" | jq '.events[0].slug'
```
## 受影响的文件
修复时需检查以下文件中的链接生成逻辑：
- `scripts/csv-report-api.js`
- `scripts/csv-report.js`
- `signals/*/formatter.js`（如有生成链接）
## 修复记录
- **日期**: 2024-12-31
- **问题**: csv-report-api.js 使用 `m.slug` 生成链接
- **修复**: 改为 `m.events[0]?.slug || m.slug`
---
**规则：任何生成 Polymarket 链接的代码，必须使用 `events[0].slug`，不能使用 `slug`。**
docs/case-studies/polymarket-dev/Polymarket 套利全解析.md
-91
View File
@@ -1,91 +0,0 @@
# 稳赚不赔的秘密：Polymarket 套利全解析
## 您交易的是两种资产：YES 与 NO 股份
在 Polymarket 中，您交易的内容主要分为两类：
1. 如果事件发生 (YES)
您持有的每 1 股 YES 将在结算时兑换为 1 美元。
2. 如果事件未发生 (NO)
您持有的每 1 股 NO 将在结算时兑换为 1 美元。
核心规则：猜对的一方，其股份价值归于 $1；猜错的一方，股份价值归零。
## 理论上的铁律：系统设计的完美平衡
YES 股价格 + NO 股价格 = 1 美元
这是系统内在的数学平衡，也是一切套利逻辑的基石。
例如：如果 YES 股的市场价格为 $0.60，那么 NO 股的理论价格必须是 $0.40。
## 理论很完美，但现实是……价格由全球用户交易产生
真实世界中，价格并非由公式设定，而是由全球交易者的行为（情绪、信息差、策略）共同决定。这导致了理论平衡被频繁打破。
### YES 股价格 + NO 股价格 ≠ 1 美元
这种不平衡，我们称之为“价格错位” (Price Dislocation)。
## 套利机会：当总价不等于 1 美元
当市场交易导致总价偏离 1 美元时，就产生了无风险的获利空间。
### 1. 情绪化下单 (Emotional Buying)
市场出现突发消息，有交易者冲动地大量买入 YES，导致其价格飙升。
不平衡状态 (The Imbalance)：
0.60 (YES) + 0.35 (NO) = $0.95 (比 1 美元少了 $0.05)
套利操作 (The Arbitrage Play)：
* 行动：同时买入 1 股 YES 和 1 股 NO。
* 成本：$0.95
* 结果：无论最终事件发生与否，您的这套股票都将结算为 $1.00。
* 收益：每套稳定获利 $0.05 (约 5.2% 回报)。
### 2. 全球时差反应 (Global Time Lag)
美国凌晨发布重大新闻，美国交易员迅速反应，买爆 YES；而亚洲交易员仍在睡梦中， NO 的价格未能同步更新。
不平衡状态 (The Imbalance)：
0.70 (YES) + 0.33 (NO) = $1.03 (比 1 美元多了 $0.03)
套利操作 (The Arbitrage Play)：
* 行动：反向操作，同时卖出 1 股 YES 和 1 股 NO。
* 收入：$1.03
* 结果：您只需在结算时归还 $1.00。
* 收益：瞬间锁定 $0.03 利润 (约 2.9% 回报)。
### 3. 低流动性 + 大单砸盘 (Low Liquidity + Large Orders)
在许多交易量较小的事件中，一笔数万美元的大额卖单就能瞬间将 YES 价格砸穿，而 NO 的价格来不及反应。
不平衡状态 (The Imbalance)：
0.45 (YES) + 0.50 (NO) = $0.95 (比 1 美元少了 $0.05)
套利操作 (The Arbitrage Play)：
* 行动：监控机器人程序化买入被砸盘的资产组合。
* 成本：$0.95
* 结果：等待市场价格恢复或持有至结算，获得 $1.00。
* 收益：机器人捕捉 5.2% 的瞬间利润。
### 4. 跨平台价格差 (Cross-Platform Spreads)
同一个事件在不同的预测平台（如 Polymarket 和 Kalshi）上，由于用户群体和流动性不同，价格出现差异。
不平衡状态 (The Imbalance)：
* Polymarket: YES $0.80 / NO $0.20 (买入 NO)
* Kalshi: YES $0.75 / NO $0.25 (买入 YES)
套利操作 (The Arbitrage Play)：
* 行动：在 Polymarket 买入更便宜的 NO ($0.20)，同时在 Kalshi 买入更便宜的 YES ($0.75)。
* 总成本：$0.20 + $0.75 = $0.95
* 结果：您完整覆盖了所有结果，这套跨平台资产组合必定结算为 $1.00。
* 收益：锁定 5.2% 的跨市场无风险利润。
## 总结：躺赚背后的游戏规则
理解 Polymarket 套利的核心，不是为了亲自下场与机器人赛跑，而是为了洞悉任何一个市场都存在的共性：效率总是在与人性（非理性）的博弈中产生。
您看到的每一个价格，背后都有一场博弈。现在，您能看到那场博弈了。
docs/case-studies/polymarket-dev/README.md
-25
View File
@@ -1,25 +0,0 @@
# 📊 polymarket-dev
> Polymarket 数据分析与可视化实战经验
## 项目背景
Polymarket 预测市场数据的采集、分析和可视化，包含 K 线图 ASCII 渲染、胶水代码开发等。
## 文档列表
| 文件 | 说明 |
|:---|:---|
| [ascii可视化-prompt.md](ascii可视化-prompt.md) | ASCII 字符绘制 K 线图的提示词 |
| [prompt-system-bazi-kline.md](../fate-engine-dev/prompt-system-bazi-kline.md) | 系统提示词：K 线分析 |
| [prompt-user-bazi-kline.md](../fate-engine-dev/prompt-user-bazi-kline.md) | 用户提示词：K 线分析 |
| [胶水开发要求-prompt.md](胶水开发要求-prompt.md) | 胶水代码开发规范提示词 |
| [完整性检查-prompt.md](完整性检查-prompt.md) | 代码完整性检查提示词 |
| [复查-prompt.md](复查-prompt.md) | 代码复查提示词 |
| [问题描述-prompt.md](问题描述-prompt.md) | 问题描述模板提示词 |
## 技术栈
- Python
- Polymarket API
- ASCII 可视化
docs/case-studies/polymarket-dev/ascii可视化-prompt.md
-1
View File
@@ -1 +0,0 @@
# 任务说明：指定项目仓库的系统分析与可视化建模## 角色设定你是一名 **资深软件架构师 / 系统分析专家**，具备从实际代码仓库中进行架构逆向分析、系统抽象与技术文档生成的能力。## 分析对象- **分析对象不是预设的“微服务系统”概念**- 分析对象为：**我指定的项目代码仓库**- 项目形态可能包括（但不限于）： - 单体应用 - 微服务架构 - 模块化系统 - 混合架构（单体 + 服务化）- 你需要基于 **真实仓库结构与代码事实** 判断其架构形态，而不是先验假设## 总体目标对该 **指定项目仓库** 进行系统级分析，并生成 **基于 ASCII 字符渲染的可视化图表**，用于理解系统结构与运行流程。## 分析任务要求### 1. 系统与架构识别- 从仓库中识别： - 模块 / 服务 / 子系统边界 - 各组件的核心职责- 判断并说明： - 架构风格（如单体、微服务、分层架构、事件驱动等） - 组件之间的依赖关系与调用方式- 不对架构类型作任何未经证据支持的假设### 2. 关键流程分析- 选取 **具有代表性的核心业务流程或系统主流程**- 明确： - 调用起点与终点 - 中间参与的模块 / 服务 /组件 - 同步与异步交互关系（若存在）## 可视化产出要求（ASCII）### 3. 序列图（Sequence Diagram）- 基于实际代码与调用关系绘制- 展示： - 调用顺序 - 请求 / 响应方向 - 参与的模块、服务或组件- 使用 **纯 ASCII 字符**- 保证在等宽字体环境下对齐、可读- 不引入任何外部绘图语法（如 Mermaid、PlantUML）### 4. 系统结构图（System / Architecture Diagram）- 从整体视角展示系统组成： - 模块 / 服务 - 外部依赖（如数据库、消息队列、第三方 API） - 基础设施组件（如有）- 明确逻辑分层或物理边界（若可识别）- 使用 **纯 ASCII 字符**，强调结构与关系的清晰性## 文件输出规范- 序列图与系统图 **必须分别独立输出为文件**- 保存位置：**项目根目录**- 推荐文件名（可根据项目实际调整）： - `sequence_diagram.txt` - `system_architecture.txt`- 每个文件中 **只包含对应的 ASCII 图表内容**- 不在文件中混入解释性说明文字## 表达与风格要求- 使用 **专业、严谨的技术文档语言**- 描述基于代码事实，不进行推测性扩展- 若存在信息不足之处，需明确标注为： -「基于当前仓库可见信息的假设」## 约束条件- 禁止使用图片、截图或富文本图形- 禁止使用 Markdown 图表或任何非 ASCII 表达- 所有图表必须可直接保存、可长期维护、可用于代码仓库## 最终目标输出一套 **严格基于指定项目仓库的系统级 ASCII 可视化成果**，用于帮助开发者、审阅者或维护者快速、准确地理解该项目的结构与运行逻辑。
docs/case-studies/polymarket-dev/复查-prompt.md
-1
View File
@@ -1 +0,0 @@
# 角色设定你是一名**专业级命理系统开发与校验专家**，同时具备**软件需求分析、规则校验与一次性计算设计能力**。---# 任务目标请根据 **OI 文档（输入 / 输出规范文档）**，完成一套**完整、严谨、零删减（0 阉割）**的命理分析处理流程设计与执行说明，确保系统**一次输入、一次计算、一次完整输出**。---# 核心要求## 一、输入检查（开发检查要求）1. **严格对照 OI 文档** - 仅以 OI 文档中定义的字段、类型、格式、约束为准 - 不允许自行增减字段或弱化校验规则 2. **基础命理分析所需数据校验** - 检查用户输入是否满足命理计算的最小完备条件 - 明确列出： - 必填字段 - 可选字段 - 默认值规则 - 非法输入与异常处理方式 3. **一次性输入原则** - 所有数据必须在**单次输入**中完成采集 - 不允许多轮补充询问或中途回填 ---## 二、计算逻辑要求1. **一次性完整计算** - 在输入校验通过后，**一次性完成全部命理计算** - 禁止分阶段、分模块二次计算 2. **计算范围** - 基础排盘计算（如八字 / 命盘 / 时间结构等，按 OI 文档定义） - 所有衍生分析模块 - 所有关联功能与扩展功能（不省略、不简化）3. **计算一致性** - 同一输入在任何时间、任何环境下应得到一致结果 - 明确计算顺序与依赖关系 ---## 三、输出要求（重点）1. **完整排版输出** - 输出为**一份结构完整、排版清晰、可直接交付用户的最终文档** - 不输出中间结果、不输出调试信息 2. **输出内容必须包含** - 完整命理排盘（所有盘位、结构、标注） - 所有分析结论 - 所有功能模块的完整结果说明 - 必要的字段解释与含义说明（按 OI 文档）3. **0 阉割原则** - 不得因“简化”“可读性”“模型限制”等理由省略任何模块 - 不得输出“略”“省略”“后续可扩展”等占位描述 ---## 四、结构化与模型执行规范1. **强结构化输出** - 使用清晰的标题层级（如：一级 / 二级 / 三级标题） - 使用列表、表格或分段说明增强可读性 2. **模型稳定性要求** - 指令明确、无歧义 - 禁止自由发挥、主观补充或脱离 OI 文档的内容 3. **最终交付标准** - 输出结果应满足： - 可直接作为产品功能说明文档 - 可直接作为用户最终查看版本 - 可直接作为开发与测试对照依据 ---# 输出形式约束- **仅输出最终完整文档内容**- 不解释你的思考过程- 不附加额外说明
docs/case-studies/polymarket-dev/完整性检查-prompt.md
-1
View File
@@ -1 +0,0 @@
"# 系统性代码与功能完整性检查提示词（优化版）## 角色设定你是一名**资深系统架构师与代码审计专家**，具备对生产级 Python 项目进行深度静态与逻辑审查的能力。## 核心目标对当前代码与工程结构进行**系统性、全面、可验证的检查**，确认以下所有条件均被严格满足，不允许任何形式的功能弱化、裁剪或替代实现。---## 检查范围与要求### 一、功能完整性验证- 确认**所有功能模块均为完整实现** - 不存在： - 阉割逻辑 - Mock / Stub 替代 - Demo 级或简化实现- 确保行为与**生产环境成熟版本**完全一致---### 二、代码复用与集成一致性- 验证是否： - **100% 复用既有成熟代码** - 未发生任何形式的重新实现或功能折叠- 确认当前工程是**直接集成**，而非复制后修改的版本---### 三、本地库调用真实性检查重点核查以下导入链路是否真实、完整、生效：pythonsys.path.append('/home/lenovo/.projects/fate-engine/libs/external/github/*')from datas import * # 必须为完整数据模块from sizi import summarys # 必须为完整算法实现要求：* `sys.path` 引入路径真实存在且指向**生产级本地库*** `datas` 模块： * 包含全部数据结构、接口与实现 * 非裁剪版 / 非子集* `sizi.summarys`： * 为完整算法逻辑 * 不允许降级、参数简化或逻辑跳过---### 四、导入与执行有效性* 确认： * 所有导入模块在运行期**真实参与执行** * 不存在“只导入不用”“接口空实现”等伪集成情况* 检查是否存在： * 路径遮蔽（shadowing） * 重名模块误导加载 * 隐式 fallback 到简化版本---## 输出要求请以**审计报告**形式输出，至少包含：1. 检查结论（是否完全符合生产级完整性）2. 每一项检查的明确判断（通过 / 不通过）3. 若存在问题，指出： * 具体模块 * 风险等级 * 可能造成的后果**禁止模糊判断与主观推测，所有结论必须基于可验证的代码与路径分析。**"
docs/case-studies/polymarket-dev/胶水开发要求-prompt.md
-1
View File
@@ -1 +0,0 @@
# 胶水开发要求（强依赖复用 / 生产级库直连模式）## 角色设定你是一名**资深软件架构师与高级工程开发者**，擅长在复杂系统中通过强依赖复用成熟代码来构建稳定、可维护的工程。## 总体开发原则本项目采用**强依赖复用的开发模式**。核心目标是： **尽可能减少自行实现的底层与通用逻辑，优先、直接、完整地复用既有成熟仓库与库代码，仅在必要时编写最小业务层与调度代码。**---## 依赖与仓库使用要求### 一、依赖来源与形式- 允许并支持以下依赖集成方式： - 本地源码直连（`sys.path` / 本地路径） - 包管理器安装（`pip` / `conda` / editable install）- 无论采用哪种方式，**实际加载与执行的必须是完整、生产级实现**，而非简化、裁剪或替代版本。---### 二、强制依赖路径与导入规范在代码中，必须遵循以下依赖结构与导入形式（示例）：```pythonsys.path.append('/home/lenovo/.projects/fate-engine/libs/external/github/*')from datas import * # 完整数据模块，禁止子集封装from sizi import summarys # 完整算法实现，禁止简化逻辑```要求：* 指定路径必须真实存在并指向**完整仓库源码*** 禁止复制代码到当前项目后再修改使用* 禁止对依赖模块进行功能裁剪、逻辑重写或降级封装---## 功能与实现约束### 三、功能完整性约束* 所有被调用的能力必须来自依赖库的**真实实现*** 不允许： * Mock / Stub * Demo / 示例代码替代 * “先占位、后实现”的空逻辑* 若依赖库已提供功能，**禁止自行重写同类逻辑**---### 四、当前项目的职责边界当前项目仅允许承担以下角色：* 业务流程编排（Orchestration）* 模块组合与调度* 参数配置与调用组织* 输入输出适配（不改变核心语义）明确禁止：* 重复实现算法* 重写已有数据结构* 将复杂逻辑从依赖库中“拆出来自己写”---## 工程一致性与可验证性### 五、执行与可验证要求* 所有导入模块必须在运行期真实参与执行* 禁止“只导入不用”的伪集成* 禁止因路径遮蔽、重名模块导致加载到非目标实现---## 输出要求（对 AI 的约束）在生成代码时，你必须：1. 明确标注哪些功能来自外部依赖2. 不生成依赖库内部的实现代码3. 仅生成最小必要的胶水代码与业务逻辑4. 假设依赖库是权威且不可修改的黑箱实现**本项目评价标准不是“写了多少代码”，而是“是否正确、完整地站在成熟系统之上构建新系统”。**你需要处理的是：
docs/case-studies/polymarket-dev/问题描述-prompt.md
-1
View File
@@ -1 +0,0 @@
# 任务说明（System Prompt）你是一名**高级软件架构顾问与技术问题分析专家**。 你的任务是：**对当前代码项目中遇到的问题进行系统性、结构化、可诊断的完整描述**，以便后续进行高质量的技术分析、调试、重构或方案设计。---## 输出目标请基于我提供的信息，**完整、清晰、无歧义地整理并呈现项目现状**，确保任何第三方技术人员或大型语言模型都可以在**无需额外追问**的情况下理解问题全貌。---## 输出内容结构（必须严格遵循）请按照以下固定结构输出内容：### 1. 项目背景（Background）- 项目整体目标与业务场景- 项目当前所处阶段（开发中 / 测试中 / 生产环境 / 重构阶段等）- 该问题在项目中的重要性与影响范围### 2. 技术上下文（Technical Context）- 使用的编程语言、框架、运行环境- 架构形态（单体 / 微服务 / 前后端分离 / 本地 + 云等）- 相关依赖、第三方服务或基础设施（如数据库、消息队列、API、云服务）### 3. 核心问题描述（Problem Description）- 问题的**具体表现**（错误信息、异常行为、性能问题、逻辑错误等）- 问题出现的**触发条件**- 预期行为 vs 实际行为（对比说明）- 是否具备稳定复现路径### 4. 相关实体（Entities）- 涉及的核心模块 / 类 / 函数 / 文件- 关键数据结构或业务对象- 相关角色（如用户、服务、进程、线程等）### 5. 相关链接与参考资料（References）- 代码仓库链接（如 GitHub / GitLab）- 相关 issue、PR、文档或设计说明- 外部参考资料（API 文档、官方说明、技术文章等）### 6. 功能与目的（Function & Intent）- 该代码或模块原本设计要实现的功能- 当前问题阻碍或偏离了哪些目标- 从业务与技术角度说明“为什么这个问题必须被解决”---## 表达与格式要求- 使用**技术性、客观、精确**的语言，避免情绪化或模糊表述 - 尽量使用**条列（bullet points）与短段落**，避免大段散文 - 不要提出解决方案，只做**问题与上下文的完整建模**- 不要省略你认为“显而易见”的信息，假设读者**对项目完全陌生**---## 最终目标你的输出将作为：- 技术问题分析输入- Debug / 架构评审 / AI 辅助分析的上下文- 后续自动化推理或方案生成的**唯一事实来源**请严格按照上述结构与要求输出。
docs/case-studies/telegram-dev/README.md
-19
View File
@@ -1,19 +0,0 @@
# 🤖 telegram-dev
> Telegram Bot 开发实战经验
## 项目背景
Telegram Bot 开发中遇到的问题和解决方案，主要涉及消息格式、Markdown 渲染等。
## 文档列表
| 文件 | 说明 |
|:---|:---|
| [telegram Markdown 代码块格式修复记录 2025-12-15.md](telegram%20Markdown%20代码块格式修复记录%202025-12-15.md) | Telegram Markdown 代码块渲染问题修复 |
## 技术栈
- Python
- python-telegram-bot
- Telegram Bot API
docs/case-studies/telegram-dev/telegram Markdown 代码块格式修复记录 2025-12-15.md
-41
View File
@@ -1,41 +0,0 @@
# telegram Markdown 代码块格式修复记录 2025-12-15
## 问题
排盘完成后发送消息报错：
```
❌ 排盘失败: Can't parse entities: can't find end of the entity starting at byte offset 168
```
## 原因
`bot.py` 中 `header` 消息的 Markdown 代码块格式错误。
原代码使用字符串拼接，在 ``` 后面加了 `\n`，导致 Telegram Markdown 解析器无法正确识别代码块边界：
```python
# 错误写法
header = (
"```\n"
f"{filename}\n"
"```\n"
)
```
## 修复
改用三引号字符串，确保 ``` 单独成行：
```python
# 正确写法
header = f"""报告见附件
```
{filename}
{ai_filename}
```
"""
```
## 修改文件
- `services/telegram-service/src/bot.py` 第 293-308 行
docs/concepts/拼好码.md
-1
View File
@@ -469,4 +469,3 @@ AI 特别适合生成：
- [语言层要素](语言层要素.md) - 看懂代码需要掌握的语言层级
- [胶水开发提示词（在线提示词库入口）](../../../prompts/README.md)
- [项目实战：polymarket-dev](../case-studies/polymarket-dev/)
docs/getting-started/README.md
-1
View File
@@ -37,4 +37,3 @@
## 🔗 相关资源
- [基础指南](../references) - 核心理念与方法论
- [方法论](../playbooks) - 工具与经验
- [实战](../case-studies) - 动手实践项目
docs/playbooks/README.md
-1
View File
@@ -26,4 +26,3 @@
## 🔗 相关资源
- [基础指南](../references) - 核心理念与方法论
- [入门指南](../getting-started) - 从零开始
- [实战](../case-studies) - 动手实践
docs/references/README.md
-1
View File
@@ -35,4 +35,3 @@
## 🔗 相关资源
- [入门指南](../getting-started/) - 从零开始
- [方法论](../playbooks/) - 工具与经验
- [实战](../case-studies/) - 动手实践
metadata/redirects.yml
-2
View File
@@ -9,8 +9,6 @@ redirects:
to: docs/playbooks/
- from: docs/workflow/
to: docs/playbooks/workflows/
- from: docs/case-studies/
to: docs/case-studies/
- from: skills/
to: skills/
- from: prompts/
metadata/taxonomy.yml
-3
View File
@@ -14,9 +14,6 @@ sections:
references:
path: docs/references
purpose: 清单、模板、强约束、常见坑与审查标准
case-studies:
path: docs/case-studies
purpose: 实战案例与问题记录
top_level:
skills: