背景：上班时候有个突发的小业务，少量数据出现了一些比较奇怪的情况，需要采集出来
这些数据行的数量说多不多，没必要上 sql 直接前端页面就能看到（实际上是不了解这项业务的数据库字段懒得翻）
说少也不少，如果真人工来干就很麻烦
对于 AI 来说 html 又太多了，吃不下。于是我打算让 AI 生成执行小段任务的代码进行自动化
我当时只和他对话了一次就跑通了（突然间很惊讶，可能是最近学习 DDD 的用例分析提升了一点分析和描述需求的能力）
前端用的是 layui （我发现他居然是表头渲染了一个 table，内容部分又是一个table ）具体情况不多说，上提示词
为我生成一段js浏览器脚本，在控制台中使用
网页大致内容如下：
1. 整个页面中有两个table，第一个table我们把他称为表头table，第二个table我们把他称为内容table
2. 表头table负责渲染表头，也就是说，你查询第一个table的 th 所有标签，能得到所有表头单元格
3. 内容table负责渲染数据行，查询第二个table中的tr标签能获取所有数据行，再到第二个table里面的每行中查询td能获得一行中的所有内容单元格，且数组索引位置和对应的表头索引是同一列
你需要编写一段脚本，大致流程如下：
1. 你需要先查询两个table，第一个是表头table，第二个是内容table
2. 你需要在表头table中确定 "ID"、"姓名"、"渠道名称"这三个表头单元格在表头table的表头单元格当中的索引
3. 根据表头单元格的索引，你就能确定这一列在内容table中的每一行的数据归属。这个时候你需要判断内容table中每一行的 "渠道名称" 字段是不是"xxxx",如果是就把这一行的这三个字段记录下来,如果不是那就跳过这一行
4. 你需要记录符合条件的行的对应数据，存入数组中并最后导出成csv的格式
你需要额外注意：
1. 对于页面dom中文字的获取，你需要过滤换行符和双边空格，保持需要数据的纯净，甚至是去除单元格dom文字中的所有空格
这段提示词主要是三段式
第一段介绍网页内容，这个可以认为是设置环境变量或者称作上下文变量
// "整个页面中有两个table" 这一句可以看作是编程中的定义变量类型
1. 整个页面中有两个table，第一个table我们把他称为表头table，第二个table我们把他称为内容table
// "第一个table我们把他称为表头table" 这一句可以看作是给数据块分配语义化变量名称
// 对于具体一点的小需求来说，这种语义化命名能方便后面修改提示词以及对语义内容的后续引用
// 实际上这两句算是定义 表头table 和 内容table 两个对象内部的方法
2. 表头table负责渲染表头，也就是说，你查询第一个table的 th 所有标签，能得到所有表头单元格
3. 内容table负责渲染数据行，查询第二个table中的tr标签能获取所有数据行，再到第二个table里面的每行中查询td能获得一行中的所有内容单元格，且数组索引位置和对应的表头索引是同一列
// 这部分是环境变量或者应该说背景变量部分，在后续的流程中会用到这些
第二段则是开始介绍流程任务，实际上就是把脑袋中的思路描述一遍
// 可以把第一句看作是定义一个函数 "你需要先查询两个table"，后面的两句算是传参，因为一开始在上下文变量中定义过结构和变量名称，所以用同样的词语引用就行
1. 你需要先查询两个table，第一个是表头table，第二个是内容table
// 因为是简单场景的一次性工具，所以我这里直接描述流程硬编码，不过多考虑扩展性问题
2. 你需要在表头table中确定 "ID"、"姓名"、"渠道名称"这三个表头单元格在表头table的表头单元格当中的索引
// 这一句可以看作是之前定义的函数内部的逻辑，执行一个规则并把结果赋值给一个变量
// 引用表头单元格索引，并且规划他的作用，描述一下 if 分支
3. 根据表头单元格的索引，你就能确定这一列在内容table中的每一行的数据归属。这个时候你需要判断内容table中每一行的 "渠道名称" 字段是不是"xxxx",如果是就把这一行的这三个字段记录下来,如果不是那就跳过这一行
// 对于导出 csv 或者 json 格式相对简单，直接说就行，如果有更细节的需求（比如字段顺序）可以补充说明，因为我没这个需求所以我这里只有这一句话
// 这一句话是 if 分支内的逻辑，可以看作是一个简单的 push 变量的操作，不过单从从这一个功能的字数上看好像不如直接写代码调用 push 方法，但导出格式这一句提示就比具体实现的代码更省时省力
4. 你需要记录符合条件的行的对应数据，存入数组中并最后导出成csv的格式
第三段是对于一些边界情况的处理，如果经常图方便用小工具直接从dom里拿数据方便测试的话，这种边界情况很容易就会预料到了
之后我对比了一下提示词长度和生成代码的长度（比较简单粗暴的字数对比）
一点体会就是提示词和编码其实是相通的，只是提示词是更高层次的抽象，而 AI 充当了人类逻辑到代码语言的编译器
所以提示词是编译型语言(手动狗头)
人类在 coding 的过程中涌现了很多规范、设计模式和设计思想，那么提示词为了可维护性和可拓展性会不会最后也沉淀出一套设计模式和规范，对于 AI 来主导编码我认为通过高内聚和低耦合的 DDD 架构可以做到这一点
AI 编程其实不远，据我所知似乎有部分人开始尝试 DDD 的设计思想和架构来配适 AI ，我的预期相对乐观未来三到五年内或许就有大量的实践经验的工程化工具涌现
其实我自己也在尝试 AI + DDD 来编程，目前刚起步没多久，业余时间摸索一下，越摸索就感觉可行性越高，如果感兴趣的同学可以也关注一下，后面也会把代码开源出来
混的比较多的地方其实是php相关的技术社区，之前的内容发在php技术社区上了(AI+DDD独立站挑战第三周)，目前这篇帖子算是我在php技术社区发的帖子的副产品吧，不知道放哪个分类里比较好，掘金分类多，就往掘金上放了
