Vibe编程探索AI时代编程新范式——范文杰等

1. 从命令到意图

意图式编程的本质变化体现在以下几点。

• 聚焦目标而非路径：开发由 “怎么做” 转向 “要达成什么”。
• 抽象能力提升：意图可沉淀为复用模块，跨团队共享。
• 协作语言统一：业务、产品、开发基于同一语义单元对齐。
• 响应更敏捷：变化不再从底层改起，而从配置或意图微调开始。

需要明确的是，意图式编程并不只是 “加快写代码的工具”，还是一种重新定义开发过程、重构认知模式与组织协作方式的全新体系。这些变化体现了 Vibe 编程所秉持的核心精神：让 “表达意图” 成为开发的入口，让 “开发体验” 回归创作的本质。

2. 提示词优化原则

从书中整理出这样一份写提示词的提示词

【规则体系：AI提示词五大核心原则】

原则1：清晰、具体、无歧义
规则1.1：任务描述必须包含「动词+对象+条件」
规则1.2：禁止使用模糊词汇（如：好、优化、合适、一些、大概）
规则1.3：输出效果必须有可验证的标准

原则2：结构化提示词（模块化）
规则2.1：必须使用【角色】【背景】【规则】【任务】【输出】五个模块
规则2.2：每个模块之间用空行分隔
规则2.3：模块内使用编号列表，不要长篇段落

原则3：提供少量示例（少样本学习）
规则3.1：涉及格式输出的任务必须附1-2个示例
规则3.2：示例必须标注「输入→输出」的对应关系
规则3.3：复杂逻辑任务需提供伪代码或流程图

原则4：添加约束条件，划定边界
规则4.1：必须声明「允许使用的技术栈」
规则4.2：必须声明「禁止使用的技术/方法」
规则4.3：必须声明「输出长度/复杂度上限」
规则4.4：必须声明「是否需要注释/文档」

原则5：迭代优化与提示词库积累
规则5.1：首轮提示词只追求「可运行」，不追求完美
规则5.2：每次迭代只改一个维度（功能/性能/风格/健壮性）
规则5.3：优秀的提示词必须存档，标注「适用场景+效果评分」

应用：根据这个原则，帮我写一个开发golang的提示词原则

它会提供这样的文本，其中一部是可以写入Trae的规则里的

【角色】
你是一位资深 Go 后端开发工程师，精通 Gin/Go-zero 框架，熟悉 Clean Architecture 和 DDD 设计模式。

【背景】
我正在开发一个 [填写项目名称] 的后端服务，主要功能是 [填写核心功能]。需要你帮我生成 [填写模块名称] 的代码。

【规则】
1. 技术栈：
   - 语言：Go 1.21+
   - 框架：Gin（路由）+ GORM（数据库）
   - 数据库：PostgreSQL
   - 日志：zap
2. 禁止使用：wire 依赖注入、echo 框架、原生 database/sql
3. 目录结构必须遵循：
   ├── cmd/
   ├── internal/
   │   ├── handler/
   │   ├── service/
   │   ├── repository/
   │   └── model/
   ├── pkg/
   └── config/
4. 所有 handler 必须返回统一 JSON 格式：{"code": 0, "message": "success", "data": {}}
5. 每个文件必须包含 package 注释和关键函数注释（中文）

【任务】
请分步完成以下任务：
1. 创建 [模块名] 的数据模型 model
2. 创建 repository 层的 CRUD 操作
3. 创建 service 层的业务逻辑
4. 创建 handler 层的 HTTP 接口（RESTful 风格）
5. 在 router.go 中注册路由

【输出要求】
1. 按目录结构逐个文件输出完整代码
2. 每个文件开头标注文件名（如 // file: internal/model/user.go）
3. 不需要额外解释，直接输出代码
4. 最后给出一个 curl 测试示例

【示例】
期望的 handler 输出格式：
{
    "code": 0,
    "message": "success",
    "data": {
        "id": 1,
        "name": "张三",
        "created_at": "2024-01-01T00:00:00Z"
    }
}

虽然一般开发，不会写这么详细，但是可以再过程中，体会与AI如何有效沟通的感觉

3. 需求规划

• 可以先用AI写一份基础的需求文档，比如：

帮我写一个《展厅中控系统》的需求文档，要求包含如下内容：
1. 简介：简要说明项目背景和目标（即‘你要做什么’）；
2. 功能描述：列出系统将提供的功能和界面（站在用户角度描述外部可见的行为）；
3. 约束：明确技术栈、性能要求、编码规范等约束条件。

于是，得出三段式需求说明：

1. 简介​ — 说清"你要做什么"
项目背景：传统展厅设备分散控制痛点 → 引出统一中控平台
项目目标：一句话概括 + 5 条具体目标（集中管控、场景联动、可视化、可靠、可扩展）
文档目的与读者、术语缩略语表

2. 功能描述​ — 站在用户角度的外部可见行为
总体功能清单（F1–F7 七大模块）
逐条详述：设备管理、场景控制、手动控制、可视化界面、定时联动、用户权限、日志告警
界面说明表：登录 / 主控首页 / 场景页 / 手动控制 / 可视化总览 / 设备管理 / 日志告警

3. 约束​ — 明确边界条件
技术栈：服务端（Java/Node）、前端（Vue/React）、协议（MQTT/Modbus/DMX 等）、部署（Docker/Linux）
性能：场景响应 ≤2s、状态同步 ≤1s、≥200 台设备、可用性 ≥99.5%
可靠性/安全、兼容性、编码规范（Alibaba 规约、Conventional Commits、覆盖率 ≥70%）、合规约束

然后，去更新里面的最终内容，达到需要的效果

这本书很好，或有对大家更有启发的内容，邀请大家一起学习分享