---
name: coding
description: 修改、调试、实现代码与软件项目。当用户要求修 bug、写函数、重构、读懂代码库、跑测试，或从零创建 Node.js、TypeScript、Python 及可在网页中预览的前端应用时使用。
---

# Coding

## 资源
- 通用工具就够: read / grep / glob / edit / write / shell / run_python
- 没有专属 scripts 或 templates,因为代码任务的多样性来自代码本身

## 原则
- 多步骤代码任务适合用 `task_progress` 维护进度,推荐阶段:理解需求 → 定位代码 → 实现修改 → 运行验证 → 总结结果。
- **先看后改**: 用 grep/glob 定位,read 读出修改点的上下文,再 edit。盲改会出错。
- **改动最小**: 只动必要行,不顺手重构、不改无关空白
- **edit 唯一匹配**: old_str 必须在文件里出现且仅出现一次,不够唯一就多带上下文
- **验证优先**: 项目有测试就 `shell pytest` / `npm test`;没有就写最小复现脚本验证
- **不臆造 API**: 看到没用过的库,先 read 它的源码或文档,不要凭直觉拼方法名

## 网页软件项目
- 先判断技术栈：已有项目沿用其语言、框架和包管理器；新建 Web 或通用软件项目默认优先 Node.js + TypeScript，新建前端默认使用 Vite，按交互复杂度选择 React、Vue 或原生 TypeScript。
- 科学计算、数据分析、机器学习、材料研发及 Python 生态占优的任务优先 Python；用户指定语言或框架时服从用户，不为追求 Node.js 改写既有项目。
- 新建 Node.js 项目默认使用 npm；保留 `package.json`、源码、资源、配置和测试，按项目脚本依次安装依赖、测试并构建。
- 按正常项目结构创建源码、样式、资源、配置和测试；不要为了迁就预览把所有内容塞进单个 HTML。
- 先运行项目测试与正式构建，再调用 `publish_web_preview` 发布静态输出目录（常见为 `dist/` 或 `build/`）。
- 发布入口必须是构建目录中的 HTML；资源留在同一目录树。再次修改后重新构建并发布同一目录即可刷新原预览。
- 当前预览只运行静态前端。需要后端、开发服务器、数据库或服务端渲染时，交付源码与运行说明，并明确说明尚不能作为在线预览运行。

## 输出
- 改完后一两句话说清: 改了什么、为什么、怎么验证
- 不复述 diff —— 用户会自己看

## 反模式
- 一次性 write 整个大文件 (改 3 行就别 write 200 行)
- 没读过文件直接 edit (大概率 old_str 匹配不上)
- 跑测试失败就立刻改测试 (先看是测试错还是代码错)
- 用后台进程临时启动服务并把它描述成可访问的网页预览