AI全程驱动Chrome插件开发实战系列-第六章：核心功能开发实战 6/11

一开始我以为用AI写代码很简单：告诉AI要什么功能，它就给我写好了，复制粘贴就能用。结果发现，完全不是这么回事！ AI写的代码经常有问题：有时候理解错了需求有时候用了过时的方法有时候逻辑有漏洞有时候和现有代码冲突

上期回顾

上一章我们通过AI工具完成了完整的项目规划：

学习了CCPM项目管理方法：标准化的项目结构和文档组织
Claude设计了项目目录结构：清晰的文件组织，适合AI协作
ChatGPT制定了开发计划：按Sprint组织，4周完成MVP
Gemini设计了任务管理方法：任务卡片、工作日志、决策记录

现在万事俱备，终于要开始写代码了！

但是注意，这一章不会教你怎么写具体的代码（那是程序员的事），而是教你如何与AI协作来完成开发任务。

第六章：核心功能开发实战，用AI写出能用的代码

开发前的心态调整

在正式开始之前，我先说说我的心路历程。

一开始我以为用AI写代码很简单：告诉AI要什么功能，它就给我写好了，复制粘贴就能用。

结果发现，完全不是这么回事！

AI写的代码经常有问题：

有时候理解错了需求
有时候用了过时的方法
有时候逻辑有漏洞
有时候和现有代码冲突

所以正确的心态是：AI是助手，不是魔法。

你要：

清楚地表达需求
理解AI的输出
检查和修正问题
持续迭代改进

把AI当成一个很聪明但需要指导的新手程序员，这样心态就对了。

第一步：用CCPM管理Claude Code开发流程

什么是CCPM？

CCPM（Claude Code Project Management）是专门为Claude Code设计的项目管理系统。它不是我自己YY出来的，而是一个真实存在的开源项目。

官方地址： https://github.com/automazeio/ccpm

CCPM解决的核心问题：

上下文丢失：传统开发中，AI的对话上下文会消失，需要反复解释
串行开发：一次只能干一件事，效率低
需求漂移：口头决策覆盖书面规范，容易出错
进度不透明：不知道做到哪了，直到最后才发现问题

CCPM的核心理念：

"Every line of code must trace back to a specification."（每一行代码都必须追溯到规范）

不是靠感觉写代码（No Vibe Coding），而是：

先想清楚要做什么（Brainstorm）
写详细的规范（Document）
做技术规划（Plan）
按规范实现（Execute）
全程追踪进度（Track）

为什么CCPM用GitHub Issues？

你可能会问：为什么不用什么专门的项目管理工具，而用GitHub Issues？

CCPM的解释：

多人协作：多个Claude实例可以同时在同一个项目工作
实时可见：人类开发者通过Issue评论实时看到AI的进度
无缝切换：AI开始的任务，人可以接手（反之亦然）
透明度高：管理者不用打断工作流就能看到进度
利用现有工具：团队已经在用GitHub，不需要额外工具

核心观点：

"Issue state is the project state"（Issue的状态就是项目的状态）

CCPM的目录结构

安装CCPM后，项目会有这样的结构：

your-project/
├── .claude/
│   ├── CLAUDE.md           # 给Claude的永久指令
│   ├── agents/             # 任务导向的智能体
│   ├── commands/           # 命令定义
│   │   ├── pm/            # ← 项目管理命令（核心）
│   │   └── context/       # 上下文管理
│   ├── context/           # 项目全局上下文
│   ├── epics/             # ← 本地工作空间（加入.gitignore）
│   │   └── [epic-name]/   # 每个史诗和相关任务
│   │       ├── epic.md    # 实现计划
│   │       ├── 001.md     # 任务文件
│   │       └── updates/   # 进度更新
│   └── prds/              # ← PRD文档
└── ...你的项目代码

关键目录说明：

prds/：存放产品需求文档（PRD）
epics/：存放史诗（Epic）和任务分解，是本地工作空间
context/：存放项目全局上下文，让AI始终理解项目背景

安装和初始化CCPM

安装命令（Mac/Linux）：

cd your-project/
curl -sSL https://automaze.io/ccpm/install | bash

安装命令（Windows）：

cd your-project/
iwr -useb https://automaze.io/ccpm/install | iex

初始化步骤：

更新CLAUDE.md：

/init include rules from .claude/CLAUDE.md

把CCPM的规则加入到项目的Claude指令中。

创建项目上下文：

/context:create

让Claude了解项目的基本信息。

运行初始化命令：

/pm:init

这会安装GitHub CLI、认证GitHub、创建必要目录。

CCPM的完整工作流程

现在让我用真实的CCPM命令，展示如何管理我们的Chrome插件开发。

阶段1：创建PRD（产品需求文档）

命令：

/pm:prd-new smart-writing-assistant

Claude会做什么： 启动一个全面的头脑风暴对话，帮你创建PRD文档，包括：

产品愿景
用户故事
成功标准
技术约束

输出文件： .claude/prds/smart-writing-assistant.md

我的实际过程： Claude会问很多问题：

"这个产品要解决什么核心问题？"
"目标用户是谁？"
"如何衡量成功？"
"有什么技术限制？"

我一个个回答，Claude把我的回答整理成结构化的PRD文档。

PRD文档包含的内容：

产品概述和目标
核心功能列表
用户故事和场景
技术要求和约束
成功指标
风险和依赖

阶段2：将PRD转化为Epic（史诗）

命令：

/pm:prd-parse smart-writing-assistant

Claude会做什么： 读取PRD，转化为技术实现计划，包括：

架构决策
技术方案
依赖关系映射

输出文件： .claude/epics/smart-writing-assistant/epic.md

Epic文档包含：

技术架构设计
主要技术决策（比如为什么选Google Translate API）
实现策略
风险评估

阶段3：将Epic分解为具体任务

命令：

/pm:epic-decompose smart-writing-assistant

Claude会做什么： 把Epic分解成可执行的具体任务，每个任务都有：

明确的验收标准
工作量估算
是否可以并行执行的标记

输出文件：

.claude/epics/smart-writing-assistant/
├── epic.md
├── 001.md  # 任务1：搭建基础框架
├── 002.md  # 任务2：集成翻译API
├── 003.md  # 任务3：实现快捷键监听
└── ...

任务文件的内容： 每个任务文件包含：

任务描述
验收标准（清晰的checklist）
依赖关系（需要先完成哪些任务）
技术要点
预估工作量

阶段4：同步到GitHub

命令（推荐）：

/pm:epic-oneshot smart-writing-assistant

这个命令会一次性完成分解和同步。

或者分步执行：

/pm:epic-sync smart-writing-assistant

会发生什么：

在GitHub创建一个Epic Issue（父Issue）
为每个任务创建子Issue
建立父子关系
添加合适的标签（epic:smart-writing-assistant, task:smart-writing-assistant）

GitHub上的效果：

Issue #1234：[Epic] 智能英文写作助手
- Issue #1235：搭建Chrome Extension基础框架
- Issue #1236：集成翻译API
- Issue #1237：实现快捷键监听
- ...

本地文件重命名： 同步后，本地任务文件会根据GitHub Issue编号重命名：

001.md → 1235.md
002.md → 1236.md
003.md → 1237.md

这样issue编号和文件名一一对应，超级清晰！

阶段5：开始开发任务

查看下一个该做的任务：

/pm:next

Claude会智能推荐下一个应该做的任务，考虑：

优先级
依赖关系
当前进度

开始一个任务：

/pm:issue-start 1235

会发生什么：

Claude加载任务详情（从1235.md读取）
读取相关上下文（Epic、PRD、项目上下文）
启动专门的智能体（Agent）来处理这个任务
开始编写代码

智能体工作过程：

智能体会按照任务的验收标准一步步实现
每完成一个验收点，会在本地更新进度
可以随时用/pm:issue-sync 1235同步进度到GitHub

同步进度到GitHub：

/pm:issue-sync 1235

会在GitHub Issue #1235下添加评论，更新进度：

Progress Update:
✅ Created manifest.json
✅ Configured permissions
🔄 Setting up popup page (in progress)
⏸️ Content script setup (pending)

阶段6：完成任务

关闭任务：

/pm:issue-close 1235

会做什么：

更新本地任务文件状态为"已完成"
关闭GitHub Issue
更新Epic的进度

查看整体进度：

/pm:epic-show smart-writing-assistant

显示Epic和所有任务的状态，一目了然。

CCPM的杀手级特性：并行执行

这是CCPM最牛的地方，也是和其他项目管理方式最大的区别。

传统方式 vs CCPM方式

传统方式：

一个Issue = 一个开发者 = 串行执行
Epic有3个Issue，顺序完成，需要3天

CCPM方式：

一个Issue可以分解为多个并行的工作流
多个Claude智能体同时工作
同样的3个Issue，可能只需要1天

具体例子

假设有个任务："实现用户认证"

传统做法： 一个人从头到尾做完所有事情。

CCPM做法： 把这个任务分解成5个并行流：

Agent 1：数据库表和迁移
Agent 2：业务逻辑层
Agent 3：API接口
Agent 4：UI组件
Agent 5：测试代码

5个智能体同时工作！

实现原理

使用Git Worktree： 每个智能体在独立的worktree中工作，互不干扰。

协调机制： 通过Git commits协调，最后合并到一起。

GitHub视角： GitHub只看到简单的Issue和进度更新，不知道背后有多少智能体在并行工作。

如何启动并行执行

分析任务的并行可能性：

/pm:issue-analyze 1235

Claude会告诉你这个任务哪些部分可以并行。

启动整个Epic的并行执行：

/pm:epic-start smart-writing-assistant

会发生什么：

为Epic创建独立的worktree：../epic-smart-writing-assistant/
在这个worktree中启动多个智能体
每个智能体处理不同的子任务
所有工作在同一个worktree中进行

合并结果：

/pm:epic-merge smart-writing-assistant

所有智能体的工作合并到主分支，一次性完成整个Epic。

CCPM实战：我们的Chrome插件开发

现在让我展示如何用CCPM实际管理我们的项目。

第1步：创建PRD

/pm:prd-new smart-writing-assistant

我跟Claude详细讨论了产品需求，生成了完整的PRD文档。

第2步：转化为Epic和任务

/pm:prd-parse smart-writing-assistant
/pm:epic-oneshot smart-writing-assistant

Claude自动分解了任务，并同步到GitHub：

Epic #1234：智能英文写作助手
Task #1235：搭建基础框架
Task #1236：集成翻译API
Task #1237：实现快捷键监听
Task #1238：场景识别功能
...

第3步：开始第一个任务

/pm:next

Claude推荐："建议从Task #1235开始，这是基础任务，没有依赖。"

/pm:issue-start 1235

Claude启动专门的智能体，开始创建manifest.json和基础文件。

第4步：持续同步进度

开发过程中，我会定期同步：

/pm:issue-sync 1235

GitHub Issue下会更新评论：

Update at 2025-01-16 14:30:
✅ manifest.json created
✅ Permissions configured  
✅ Popup page setup complete
🔄 Content script in progress

Next: Implement keyboard listener

第5步：完成任务

/pm:issue-close 1235

任务标记完成，继续下一个：

/pm:next

"Task #1236已就绪，可以开始了。"

CCPM的核心优势

通过实际使用CCPM，我发现了它的几个巨大优势：

优势1：上下文永不丢失

传统方式的问题： 和Claude对话时间长了，它就忘记前面说的内容了。你需要反复解释项目背景。

CCPM的解决方案：

所有重要信息都写在PRD、Epic、任务文件中
每次Claude都能读取完整上下文
不需要重复解释

实际体验： 我可以随时停下来，第二天再启动Claude，它立即就能继续工作，完全知道项目状态。

优势2：并行执行，效率翻倍

传统方式： 一次只能做一件事，等这个做完才能做下一个。

CCPM方式： 多个智能体同时工作，原本需要一周的工作，可能3天就完成了。

实际效果： 官方数据显示使用CCPM的团队：

上下文切换时间减少89%
可以同时处理5-8个并行任务（原来只能1个）
Bug率降低75%
功能交付速度提升3倍

优势3：完整的可追溯性

每个功能都能追溯：

代码 → Commit → Task → Epic → PRD
为什么要这个功能？看PRD
为什么这样实现？看Epic
具体怎么做的？看Task
代码在哪里？看Commit

出问题时的价值： 能快速定位是需求问题、设计问题还是实现问题。

优势4：团队协作友好

多人同时工作：

我可以在做任务A
另一个开发者（或Claude实例）在做任务B
通过GitHub Issue实时看到彼此进度
不需要开会同步

新人加入容易：

读一遍PRD就知道项目要做什么
看Epic就知道技术方案
从任务列表选一个就能开始干活

实用技巧和注意事项

技巧1：充分利用智能推荐

不要自己决定做什么，让Claude帮你：

/pm:next

它会考虑优先级、依赖关系、工作量，给出最优建议。

技巧2：查看整体进度

随时了解项目状态：

/pm:status         # 整体项目仪表盘
/pm:standup        # 每日站会报告
/pm:in-progress    # 正在进行的工作
/pm:blocked        # 被阻塞的任务

技巧3：善用搜索

项目大了找不到东西：

/pm:search "翻译API"

搜索所有PRD、Epic、任务中的相关内容。

技巧4：定期验证

确保系统状态正确：

/pm:validate

检查文件完整性、GitHub同步状态等。

注意事项1：epics目录要加入.gitignore

.claude/epics/是本地工作空间，不要提交到Git：

# .gitignore
.claude/epics/

注意事项2：先本地后GitHub

CCPM的设计理念是"本地优先"：

所有工作先在本地完成
确认无误后再同步到GitHub
这样速度快，也避免把半成品暴露出去

注意事项3：保持PRD和代码同步

代码改了，记得更新PRD和Epic：

/pm:epic-refresh smart-writing-assistant

让Epic的进度反映实际代码状态。

本章小结：CCPM + Claude Code的威力

通过使用真实的CCPM系统，我深刻体会到了它的价值：

不再是：

❌ 对着Claude胡乱聊天，指望它能理解你的意图
❌ 写一堆代码发现需求理解错了
❌ 不知道项目做到哪了，进度不透明
❌ 一次只能做一件事，效率低下

而是：

✅ 有清晰的PRD、Epic、Task结构
✅ 每一行代码都有来源和依据
✅ 进度在GitHub Issue实时更新
✅ 多个智能体并行工作，效率翻倍

最重要的收获： CCPM不是简单的项目管理工具，而是一套与AI协作的标准化方法。它定义了：

如何组织信息让AI更好理解
如何分解任务让AI高效执行
如何保持上下文让AI不会迷失
如何并行工作让AI发挥最大价值

这才是2025年AI辅助开发的正确姿势！

接下来：实际开发核心功能新**

TASK-002已完成。

请检查是否需要更新其他文档：
1. architecture.md是否需要补充实现细节
2. 是否需要更新API文档
3. 是否需要记录技术决策
4. 是否需要更新README的进度说明

如有需要，请更新相应文档。

这就是完整的CCPM驱动开发流程！

CCPM + Claude Code的优势

优势1：上下文永不丢失

所有信息都在文档中
AI随时能查阅完整历史
不需要反复解释背景

优势2：任务追踪自动化

任务状态自动更新
工作日志自动生成
进度一目了然

优势3：知识沉淀

每个决策都有记录
每个问题都有解决方案
形成可复用的知识库

优势4：团队协作友好

新人能快速上手
所有人看相同文档
减少沟通成本

实际使用技巧

技巧1：善用相对路径 在提示词中使用相对路径，让AI自己找文档：

参考docs/03-design/architecture.md的第3节...

技巧2：建立检查清单 每个阶段结束时让AI检查：

Sprint 1结束了，请检查：
1. 所有任务都已关闭？
2. 文档都已更新？
3. 是否有遗留问题需要记录？

技巧3：定期同步 每天让AI同步文档和代码：

请检查docs/和src/是否一致：
1. 代码是否实现了PRD的所有功能
2. 架构文档是否反映了实际代码结构
3. 如有不一致，提醒我更新

技巧4：善用模板 CCPM提供了各种模板，让AI填充：

基于docs/templates/task-template.md创建新任务卡片...

第二步：用Claude Code搭建基础框架

什么是Claude Code？

Claude Code是Anthropic推出的命令行工具，让Claude能够直接在你的项目里写代码、修改文件、运行命令。

和普通对话AI的区别：

普通对话：你问，AI答，你复制粘贴
Claude Code：你说需求，AI直接在项目里改文件

为什么用Claude Code：

效率更高，不用复制粘贴
AI能看到整个项目结构
可以直接测试和验证
修改和迭代更方便

准备工作

安装Claude Code： 按照官方文档（https://docs.claude.com/en/docs/claude-code）安装，配置好API密钥。

在项目目录启动： 进入我们的smart-writing-assistant目录，运行Claude Code。

第一个任务：创建manifest.json

这是Chrome插件最核心的配置文件，定义了插件的名称、权限、功能等等。

我对Claude Code说的话：

我要创建一个Chrome插件的manifest.json文件。这个插件叫"智能英文写作助手"，主要功能是帮用户翻译中文到英文。

需求：
1. 使用Manifest V3（这是最新标准）
2. 需要的权限：storage（存储数据）、activeTab（访问当前标签）、scripting（注入脚本）
3. 需要一个popup页面（点击插件图标显示）
4. 需要content script（在网页上运行的脚本）
5. 需要配置快捷键Ctrl+Shift+T

请创建这个文件，并且：
- 添加详细的注释说明每个配置的作用
- 设置合适的版本号（从1.0.0开始）
- 配置好图标路径（虽然现在还没有图标文件）

参考我们的PRD文档：docs/02-requirements/prd.md

Claude Code的工作过程：

读取文档：先读取了PRD文档，理解产品需求
创建文件：在项目根目录创建manifest.json
写入配置：根据需求写入配置内容
添加注释：每个配置项都有中文注释

我得到的文件（简化版）：

文件创建好了，包含了插件的基本信息、权限配置、popup和content script的路径、快捷键设置等等。

我的review：

检查版本号：✓ 1.0.0正确
检查权限：✓ 需要的权限都有了
检查快捷键：✓ Ctrl+Shift+T设置正确
检查路径：✓ 文件路径符合我们的目录结构

发现的问题： 快捷键的默认设置用了"Ctrl+T"，但这个在Chrome里是打开新标签页，会冲突！

我对Claude Code说：

快捷键配置有问题，Ctrl+T会和Chrome原生快捷键冲突。
请改成Ctrl+Shift+T，并添加Mac平台的配置（Command+Shift+T）。

Claude Code立即修正了配置。

经验总结：

AI不是万能的，会犯错误
你要有基本的判断能力
发现问题立即指出，AI会快速修正
多次迭代比一次性完美更实际

第二步：创建popup界面

popup就是点击插件图标后弹出的小窗口，这是用户的主要交互界面。

我的设计思路

根据第四章的UI设计，popup界面应该包括：

顶部标题和设置按钮
翻译方向切换（中→英 / 英→中）
当前场景模式显示
快捷功能按钮（历史、词典等）

我对Claude Code说的话：

创建popup界面，包括HTML、CSS和JavaScript文件。

参考文档：
- UI设计：docs/03-design/ui-design.md
- 交互流程：docs/03-design/ui-design.md中的交互部分

需求：
1. 创建popup.html，按照设计稿的布局
2. 创建popup.css，实现视觉设计规范
3. 创建popup.js，实现基础的交互逻辑

界面要求：
- 宽度400px，高度自适应（最大600px）
- 使用设计规范中的色彩方案（主色#2196F3）
- 支持浅色和深色主题切换
- 布局要清晰，按钮要大（方便点击）

功能要求：
- 翻译方向切换按钮
- 场景模式显示和切换
- 设置页面跳转
- 基础的状态显示

先做一个简化版本，只包含核心UI，不用实现实际功能。

Claude Code的工作流程：

读取UI设计文档：理解界面布局和视觉规范
创建HTML结构：按照设计创建页面骨架
编写CSS样式：实现视觉效果
添加JavaScript：实现基础交互

我得到了三个文件：

src/popup/popup.html - 页面结构
src/popup/popup.css - 样式表
src/popup/popup.js - 交互脚本

测试popup界面

在Chrome中加载插件：

打开Chrome，进入扩展程序页面
开启"开发者模式"
点击"加载已解压的扩展程序"
选择我们的项目目录

测试结果：

✓ 插件成功加载
✓ 点击图标能弹出popup窗口
✓ 界面布局基本正确
✗ 颜色和间距有些不对
✗ 按钮点击没有反应

问题修复：

问题1：颜色不对

设计规范中主色是#2196F3，但你用的是#1976D2。
请按照docs/03-design/ui-design.md中的色彩规范重新调整所有颜色。

问题2：按钮没反应

按钮点击没有效果。请添加点击事件处理：
- 翻译方向切换按钮：切换显示"中→英"和"英→中"
- 场景模式按钮：弹出场景选择菜单
- 设置按钮：打开设置页面

Claude Code快速修复了这些问题。

经验总结：

先做出来，再慢慢完善
实际测试很重要，不能只看代码
小问题及时修，不要积累
AI理解设计文档的能力还不错

第三步：实现核心翻译功能

这是整个插件的核心功能，也是最复杂的部分。

功能分解

把复杂任务分解成小任务：

集成翻译API
监听快捷键
获取输入框内容
调用翻译
替换原文
处理错误

任务3.1：集成翻译API

我对Claude Code说：

创建翻译引擎模块，支持Google Translate API。

需求：
1. 创建src/services/translator.js文件
2. 实现翻译功能，支持中英互译
3. 添加错误处理和重试机制
4. 实现结果缓存，避免重复翻译

技术细节：
- 使用Google Translate的免费API（通过RapidAPI访问）
- API调用要异步处理
- 翻译失败要有友好提示
- 缓存使用chrome.storage.local

参考：docs/03-design/architecture.md中的翻译引擎设计

遇到的问题：

问题1：API密钥怎么管理？ 不能把密钥硬编码在代码里，那样不安全。

解决方案：

创建config.js配置文件
使用环境变量（开发和生产分离）
在.gitignore中忽略配置文件

问题2：免费API有调用限制怎么办？ Google Translate免费额度每天500次，可能不够用。

解决方案：

实现本地缓存，减少API调用
添加请求频率限制
准备备用方案（DeepL API）

我继续对Claude Code说：

翻译功能基本完成，但需要增加：
1. 请求频率限制：每分钟最多10次
2. 本地缓存：翻译过的内容缓存7天
3. 备用API：如果Google失败，自动切换到DeepL

同时创建一个简单的测试页面，让我能测试翻译功能是否正常工作。

任务3.2：监听快捷键和获取内容

这部分要在content script中实现，因为需要操作网页内容。

我对Claude Code说：

创建content script，实现快捷键监听和文本获取。

需求：
1. 创建src/content/content.js文件
2. 监听快捷键（Ctrl+Shift+T）
3. 获取当前焦点的输入框
4. 读取输入框中的文本内容
5. 支持各种类型的输入框（input、textarea、contenteditable等）

技术挑战：
- 不同网站的输入框结构不同
- 要兼容富文本编辑器
- 避免在不该触发的地方触发（比如密码框）

先实现基础版本，支持最常见的input和textarea。

测试过程：

测试场景1：GitHub的issue输入框

输入中文："这个功能很好用"
按Ctrl+Shift+T
结果：成功获取到文本

测试场景2：Reddit的评论框

输入中文："这个帖子很有意思"
按Ctrl+Shift+T
结果：没反应！

问题分析： Reddit用的是contenteditable的富文本编辑器，不是普通的textarea。

解决方案：

Reddit的评论框获取失败。它使用了contenteditable属性。
请增加对contenteditable元素的支持，并测试以下网站：
- GitHub issue编辑器
- Reddit评论框
- Gmail邮件编辑器

任务3.3：实现翻译替换

把前面的功能串起来：获取文本 → 翻译 → 替换。

我对Claude Code说：

整合翻译流程，实现完整的翻译替换功能。

流程：
1. 用户按快捷键
2. 检测当前焦点元素
3. 获取文本内容
4. 显示加载提示（"翻译中..."）
5. 调用翻译API
6. 替换原文为翻译结果
7. 显示成功提示
8. 保存翻译历史

错误处理：
- 如果没有焦点元素：提示"请先点击输入框"
- 如果内容为空：提示"没有内容需要翻译"
- 如果翻译失败：提示具体错误信息
- 如果网络错误：提示"网络连接失败，请重试"

用户体验：
- 翻译过程中显示loading动画
- 成功后显示小的成功提示（2秒后自动消失）
- 支持Ctrl+Z撤销翻译

实际测试：

场景1：基础翻译

在GitHub的issue编辑器输入："这个bug很严重，需要尽快修复"
按Ctrl+Shift+T
2秒后变成："This bug is critical and needs to be fixed as soon as possible"
✓ 成功！

场景2：撤销功能

翻译完成后按Ctrl+Z
✗ 没反应，原文没恢复

问题分析： 撤销功能需要保存原文，并且监听Ctrl+Z。

继续优化：

撤销功能不工作。需要：
1. 翻译前保存原文到内存
2. 监听Ctrl+Z快捷键
3. 恢复原文内容
4. 只能撤销最近一次翻译

同时优化翻译提示的显示位置，现在的提示太突兀了。
最好在输入框的右下角显示一个小的浮动提示。

第四步：实现场景识别功能

让翻译能根据不同网站调整风格，这是我们的差异化功能。

场景识别的思路

怎么判断场景？

通过URL判断：github.com → 技术场景
通过页面特征判断：有代码块 → 技术场景
用户手动选择：可以手动切换

不同场景的差异：

技术场景：用词专业、简洁直接
商务场景：正式礼貌、用词得体
社交场景：轻松随意、口语化

实现过程

我对Claude Code说：

实现场景自动识别功能。

需求：
1. 创建src/services/context-detector.js
2. 根据URL自动识别网站类型
3. 支持的网站：
   - github.com、stackoverflow.com → 技术场景
   - gmail.com、outlook.com → 商务场景  
   - reddit.com、twitter.com → 社交场景
   - 其他网站 → 默认场景

4. 在popup中显示当前场景
5. 允许用户手动切换场景（切换后记住偏好）

技术实现：
- URL匹配用正则表达式
- 场景信息保存到chrome.storage
- 在翻译时根据场景调整提示词

参考：docs/02-requirements/prd.md中的场景感知翻译部分

关键改进：

改进1：调整翻译提示词 不同场景给翻译API发送不同的提示：

技术场景："翻译成专业的技术英语，保持术语准确"
商务场景："翻译成正式的商务英语，语气礼貌专业"
社交场景："翻译成自然的口语化英语，语气轻松友好"

改进2：场景指示器 在popup中增加场景指示器，让用户知道当前是什么场景。

测试效果：

同一句话在不同场景：

原文："这个方案不太好，建议重新考虑"
技术场景："This approach is not optimal, suggest reconsidering"
商务场景："We might want to reconsider this proposal"
社交场景："This idea isn't great, maybe think it over?"

效果分析：

技术场景：简洁直接，用词专业
商务场景：委婉礼貌，用了"might want to"
社交场景：口语化，用了"isn't"和"maybe"

确实有差异！虽然不是完美，但已经能体现出不同场景的特点。

第五步：处理各种边界情况

真正的产品和demo的区别就在边界情况的处理。

常见的边界情况

1. 网络问题

用户断网了怎么办？
API响应超时怎么办？
API服务挂了怎么办？

解决方案：

检测网络状态
设置请求超时（5秒）
提供离线模式（基础词典）

2. 内容问题

用户输入空白内容
用户输入超长内容（超过API限制）
用户输入的是纯英文
用户输入了代码

解决方案：

内容验证，给出友好提示
长内容分段翻译
检测语言，避免无意义翻译
识别代码块，跳过不翻译

3. 兼容性问题

某些网站的输入框很特殊
某些网站禁止了插件
某些网站的DOM结构很复杂

解决方案：

建立网站兼容性列表
提供手动模式（复制粘贴翻译）
持续收集问题网站，逐步适配

实际处理

我对Claude Code说：

增加边界情况处理，让产品更健壮。

需求：
1. 网络检测：翻译前检查网络状态
2. 内容验证：
   - 空内容提示
   - 超长内容（超过500字）提示
   - 纯英文内容提示"无需翻译"
   - 代码内容跳过翻译

3. 错误恢复：
   - API失败自动重试1次
   - 超时提示用户检查网络
   - 提供"复制原文"的备用方案

4. 用户引导：
   - 第一次使用显示引导
   - 常见问题的帮助提示

增加这些处理后，让产品更加健壮和友好。

测试各种异常：

测试1：断网情况

关闭WiFi
尝试翻译
提示："网络连接失败，请检查网络设置"
✓ 正常处理

测试2：超长文本

输入1000字的中文
尝试翻译
提示："内容过长，建议分段翻译"
✓ 正常处理

测试3：纯英文输入

输入："This is a test"
尝试翻译
提示："检测到英文内容，无需翻译"
✓ 正常处理

开发过程中的真实体验

好的方面

效率提升明显：

基础代码AI生成，节省60%时间
重复性工作AI代劳，专注核心逻辑
文档和代码能保持同步

学习效果好：

AI的代码可以当教材学习
不懂的地方直接问AI
快速掌握新技术

迭代速度快：

发现问题立即修复
小步快跑，频繁验证
不怕推倒重来

遇到的坑

坑1：AI理解偏差 有时候你说A，AI理解成B。要多次沟通才能对齐。

教训：

需求要描述具体
给出清晰的示例
多轮迭代调整

坑2：AI代码质量不稳定 有时候写得很好，有时候Bug一堆。

教训：

必须自己review
重要功能多测试
不能盲目信任AI

坑3：上下文丢失 对话太长，AI会忘记之前说的内容。

教训：

重要信息写在文档里
每次任务提供完整上下文
用Claude Code比纯对话好

本章总结

通过AI辅助开发，我们完成了Chrome插件的核心功能：

开发成果：

基础框架搭建完成：manifest配置、popup界面、content script
核心翻译功能实现：集成API、快捷键、文本替换
场景识别功能上线：自动识别、手动切换、翻译优化
边界情况处理完善：网络、内容、兼容性问题

关键经验：

AI是助手不是替代：要指导、要review、要迭代
文档是协作基础：清晰的文档让AI更好理解需求
小步快跑更高效：一次做一个功能，立即测试
实际测试很重要：代码看起来对不等于真的对

最重要的是，我们证明了普通人也能用AI完成专业的开发工作。虽然过程不是一帆风顺，但通过持续沟通和迭代，最终还是做出了能用的产品。

下期预告：高级功能开发与性能优化

核心功能有了，但还不够完善。下一章我们要：

实现翻译历史功能：记录、搜索、复用历史翻译
开发个人词典系统：自定义词汇、专业术语管理
添加语法检查功能：智能检测语法错误
性能优化：减少内存占用、提升响应速度
用户体验优化：更流畅的动画、更友好的提示

**剧透：**高级功能的开发会更有挑战，因为涉及到数据管理、状态同步、性能优化等复杂问题。但有了AI的帮助，我们也能一步步解决。

想知道如何用AI实现这些高级功能吗？下期见！