1. 从一段无人船需求描述到能编译的 C 工程卡在哪智能无人船系统这类需求最麻烦的地方不是写某个算法而是把「感知—决策—控制—通信」这条链路拆成能编译、能跑、能继续填肉的 C 工程骨架。我拿到的原始需求往往就一段话无人船要支持 GPS 定位、IMU 姿态、激光/毫米波避障、路径规划、推进器差速控制、岸基 4G 回传还要有手动/自动模式切换。听起来清楚落到代码就是一堆问题模块怎么分、接口怎么定、CMake 怎么组织、第三方库怎么挂、编译报错怎么排。传统做法是人工先画架构图再一个目录一个目录建头文件里塞满前置声明最后 CMakeLists 拼半天。这个过程对熟手是体力活对刚接触工程化的小白几乎是劝退。Claude SKILL 的价值就在这里它把「自然语言需求 → 结构化模块划分 → 可编译 C 框架」这条链路固化成一个可复用的技能配置你只要把需求描述喂进去它按固定模板产出目录树、头文件接口、源文件骨架和 CMake 构建脚本。这篇要交付的是可复制的东西一份 SKILL 配置、一套提示词模板、一份无人船工程的模块拆分结果以及编译验证和排障动作。适合谁适合做机器人/嵌入式/自动驾驶方向、需要快速起工程骨架的开发者也适合想用 Claude SKILL 做工程化代码生成、但不知道怎么配的人。下面按「先配 SKILL再生成工程再编译验证再排错」的顺序走每一步都能跟着敲。需要说明的是SKILL 本身是提示词工程 工具调用的组合模型能力通过 API 调用获得。我这边统一用 TaoToken 的 API 来跑因为它同时提供模型对话和 Coding Plan配置一次 Base URL 和 Key 就能在 Claude Code、Cline 这类工具里复用省得每个工具单独折腾鉴权。2. TaoToken 前置准备Base URL、Key 与模型 ID 三件套在写 SKILL 之前先把调用通道打通。不管你是用 Claude Code、Cline 还是自己写脚本调 API核心就三样东西Base URL、API Key、Model ID。这三件套缺一个都跑不起来而且很多「连不上」的报错根源就是其中一个填错。Base URL 用https://taotoken.net/api注意这里不加任何查询参数就是干净的 API 根路径。API Key 在控制台的 API Keys 页面创建创建后只显示一次复制下来存好。Model ID 按你实际要用的模型填比如做代码生成可以选对应的 Claude 系列模型标识具体以控制台模型列表为准。如果你用 Claude Code 这类命令行工具配置通常落在 settings 文件里。下面是一份可复制的 settings 片段路径按你本机实际位置放字段名和原文保持一致{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的Key, ANTHROPIC_MODEL: 你的ModelID } }如果你用 Cline 这类 VS Code 插件配置项在插件设置里同样是三件套API Provider 选 Anthropic 兼容Base URL 填https://taotoken.net/apiAPI Key 填创建的 KeyModel ID 填模型标识。Cline 还支持 MCP如果你要把工程生成和文件写入串起来可以在 MCP 配置里挂文件系统工具但注意别把 MCP 直连到生产库本地工程目录就够了。如果你用 Codex 风格的auth.json结构大致是这样{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: 你的ModelID }三件套填完后先别急着跑 SKILL用一次最简单的对话验证通道。打开模型对话页面发一句「返回 ok」能正常返回就说明鉴权和网络都通了。这一步很关键因为后面 SKILL 生成工程时如果报 401你分不清是 Key 错还是 SKILL 配置错。通道验证通过后再进入 SKILL 配置环节。这里提醒一个常见坑Base URL 末尾不要多加/v1或斜杠不同工具对路径拼接的处理不一样多写一段就可能 404。以文档里给的地址为准拿不准就去接入文档核对一遍。3. 可复制的 SKILL 配置与无人船提示词模板SKILL 的本质是一段结构化的系统提示告诉模型「你是一个 C 工程架构师按固定规则输出」。我把它拆成三块角色约束、输出格式约束、无人船领域约束。下面这份配置可以直接复制到 Claude Code 的 skill 文件或 Cline 的自定义指令里。角色约束部分[skill] name cpp-framework-generator description 根据系统描述生成可编译的 C 工程框架 role 资深 C 工程架构师熟悉机器人、嵌入式、自动驾驶系统 rules [ 输出必须是完整目录树 每个文件的完整内容, 头文件使用 #pragma once接口用纯虚类或结构体, 源文件只写骨架和 TODO保证能编译通过, CMakeLists.txt 必须完整包含所有 target 和依赖, 不引入未声明的第三方库需要时在注释里标注 ]输出格式约束部分我要求它按固定顺序产出先给目录树再逐个文件给代码块最后给编译命令。这样你复制的时候不会漏文件。领域约束部分针对无人船把模块边界写死[domain] modules [ sensor: GPS/IMU/避障雷达数据采集与融合, perception: 障碍物检测与地图构建, planning: 全局路径规划与局部避障, control: 差速推进器 PID 控制, comm: 岸基 4G 回传与遥控指令解析, app: 主状态机手动/自动模式切换 ] interface_rule 模块间通过抽象接口通信禁止跨模块直接包含实现头文件配置好之后提示词模板这样写请根据以下系统描述生成 C 工程框架 【系统描述】 智能无人船支持 GPS 定位、IMU 姿态解算、激光雷达避障、 全局路径规划、差速推进器控制、4G 岸基通信、手动/自动模式切换。 要求模块化、接口清晰、可编译。 【输出要求】 1. 先输出完整目录树 2. 再按文件逐个输出完整代码 3. 最后输出 CMake 构建与编译命令把这段提示词和上面的 SKILL 配置一起喂给模型它就会按模块拆分产出工程。实测下来模块划分基本符合预期sensor层负责原始数据perception层做融合planning和control解耦app层做状态机。接口用纯虚类定义比如ISensor、IPlanner、IController各模块实现自己的子类。这样后面替换算法时不用动其他模块。有一点要注意模型生成的 CMakeLists 有时会漏掉某个源文件或者把target_link_libraries写错。所以生成后不要直接信先按下一节的编译验证跑一遍报错再回头改。SKILL 配置里我特意加了「CMakeLists 必须完整」这条规则能减少这类问题但不能完全避免。4. 编译验证从 cmake 配置到可执行文件跑起来工程生成后第一步是看目录结构对不对。正常应该长这样unmanned_ship/ ├── CMakeLists.txt ├── include/ │ ├── sensor/isensor.h │ ├── perception/i_perception.h │ ├── planning/i_planner.h │ ├── control/i_controller.h │ └── comm/i_comm.h ├── src/ │ ├── sensor/gps_sensor.cpp │ ├── sensor/imu_sensor.cpp │ ├── perception/obstacle_detector.cpp │ ├── planning/global_planner.cpp │ ├── control/diff_drive_controller.cpp │ ├── comm/lte_comm.cpp │ └── app/main_state_machine.cpp └── app/ └── main.cpp确认结构后进根目录执行编译。标准三步mkdir -p build cd build cmake .. make -j4如果 CMakeLists 写得规范这一步会生成可执行文件。我这边实测第一次编译通常会报两类错一是头文件路径没包含对二是某个源文件没加进add_executable。前者改target_include_directories后者补源文件路径。改完重新cmake .. make即可。编译通过后运行可执行文件验证骨架能启动./unmanned_ship正常输出类似「state machine started, mode: manual」这样的日志说明主状态机跑起来了。这时候工程骨架就算交付完成各模块里的 TODO 就是你后续填算法的地方。比如global_planner.cpp里的plan()函数现在是空实现你可以在里面接 A* 或 RRTdiff_drive_controller.cpp里的update()可以填 PID。这里给一个模块拆分检查动作避免生成后结构混乱打开include目录确认每个模块都有独立的抽象接口头文件且接口头文件不包含其他模块的实现头文件。如果发现i_planner.h里#include control/diff_drive_controller.h那就是耦合了要改成前置声明或抽到公共类型头文件。这个检查能保证后面换算法时不动其他模块。编译验证通过后如果你想继续用模型做代码补全或重构可以在模型对话里贴具体文件让它填 TODO也可以走 Coding Plan 做长期的编码任务。骨架已经在了后面就是往里面填肉。5. 常见报错排查401、local proxy failed、reading choices、OAuth生成和编译过程中报错基本集中在两类调用通道问题和工程本身问题。下面按真实报错逐个说。401 未授权最常见。原因就三个Key 填错、Key 过期、Base URL 和 Key 不匹配。排查动作先去控制台确认 Key 还在然后检查 settings 里ANTHROPIC_API_KEY有没有多余空格最后确认ANTHROPIC_BASE_URL是https://taotoken.net/api而不是别的地址。三件套里任何一个错都会 401。local proxy failed这类报错通常是本地网络配置或工具代理设置导致的。检查你的工具里有没有开本地代理端口如果有关掉再试。另外确认 Base URL 没有被工具自动拼接成奇怪路径。这个报错和通道配置强相关改完重启工具再验证。reading choices报错一般出现在响应解析阶段说明返回结构和你工具的预期不一致。常见原因是 Model ID 填错或者工具版本太旧不兼容当前返回格式。排查动作先用模型对话页面单独发一条消息确认能正常返回如果对话正常但工具报错就是工具侧解析问题升级工具或换 Model ID 再试。OAuth 相关报错多出现在 Claude Code 这类工具的登录流程里。如果你用的是 API Key 模式就不该走 OAuth。检查配置里是不是同时存在 OAuth token 和 API Key两者冲突会导致鉴权失败。清掉 OAuth 相关字段只保留三件套。工程侧报错主要是 CMake 找不到头文件、链接不到符号、源文件重复定义。找不到头文件就补target_include_directories链接不到符号通常是某个.cpp没加进 target重复定义多半是头文件里写了函数实现又没加inline。这些改完重新编译即可。排查顺序建议固定先验证通道模型对话发一条再验证工程单独编译最后验证工具集成。这样能把问题范围快速缩小不会在通道和工程之间来回猜。6. 把 SKILL 用顺手的几个实操建议SKILL 配置好之后别每次从零写提示词。把无人船那套领域约束存成模板下次做水下机器人或地面无人车只改modules列表和接口规则角色约束和输出格式约束直接复用。这样切换项目时成本很低。生成工程后第一件事永远是编译不是读代码。编译过了说明骨架自洽再去看接口设计合不合理。我踩过的坑是先生成一大堆文件然后逐个读读了半天发现 CMake 漏文件根本编不过白读。先编译再评审顺序别反。模块拆分检查要形成习惯接口头文件不依赖实现头文件模块间只通过抽象接口通信。这条守住了后面填算法、换传感器、加新模块都不会牵一发动全身。SKILL 生成的骨架如果违反这条手动改掉别将就。最后骨架只是起点。真正让无人船跑起来的是各模块里的算法实现和参数调优SKILL 帮你省掉的是搭架子的时间。把省下来的时间花在路径规划和避障策略上才是这类工具的正确用法。需要继续做代码补全或长期编码任务时走 Coding Plan 会比单次对话更顺上下文和任务连续性更好。