3. 教 AI 上班：带出我的数字同事 —— 文档返工与代码检查——明确指令与丢三落四的拉扯

3. 教 AI 上班：带出我的数字同事 ------ 文档返工与代码检查------明确指令与丢三落四的拉扯

「教 AI 上班：带出我的数字同事」系列 · 第 3 篇：又是一轮文档返工，加上代码和数据权限的检查。

前言

上一篇拿 rbac 多租户验完货，这篇接着往下推，还是两段：文档又返了一轮工，代码要做检查------数据权限和新增功能都在这段里。要求我说得很明确，它照样丢三落四：该改的状态没改，内容反倒被删空；一句"BaseDto 移到 core"能给它凭空冒出个 BaseEntity，没说动的 IdDto 也一起搬了。

来回纠正下来，我把它的工作方式一点点钉成规矩：明确说了的直接照做、别乱关联，说得模糊才允许联想；每次任务先列清单、逐条清零，不许留尾巴。文档也一样，状态改了内容不能删，空壳得按原文重写，表格、目录还要照着 SKILL 整清楚。

这篇就是这些来回拉扯的现场实录：文档返工、数据权限的暴走、功能新增的分包和缓存方案。重点不是又骂了它几句，是怎么把"明确指令"和"别丢三落四"这两件事，一点点逼成它的习惯。

一、又是文档

1.1 文档状态没改，内容还被删光

1.1.1 状态没改、内容被删

为什么前面说的文档状态这一块没有改，什么情况

复制代码

左上角的那个 文档状态	保密级别 分两行是有问题的，太难看了，只能一行才好。
为什么前面说的文档状态这一块没有改，什么情况

为什么 需求规格说明书 是空的？没有内容
现在不但我说的没改，还将所有内容都删除了，为什么？幸亏有git，不然就完了。
请一定要按我说的改完成，改正确，并且不能删除以前的内容。修改只是修改，不是删除。

1.1.2 别留空壳、按原文重写

内容不能光留个壳：按原文替换别乱改、再按正确方式重写；文档写得太潦草要重来，还要更新目录，好拿它去做原型设计：

复制代码

现在的问题是，如果内容为空，那就要按正常的生成出来，不是光搞个壳，那算什么
现在两点：
1、不要改了，按原文，用替换的方式，替换
2、按正确的方式编写文档。
  2.1 是rbac的所有功能
  2.2 docsolo的所有功能
  
你这文档写得太潦草了吧。重新编写，并且要更新目录，你不是理解了rbac的功能吗？按那个要求编写，我还要以你编写的这个文档去做原型设计呢
极光智能的英文是错的，直接去掉就行了

1.2 我重新把需求讲一遍

1.2.1 重讲系统来龙去脉

authz 是哪来的？整个系统的来龙去脉重讲一遍------为什么要做全文搜索、为什么写 rbac、权限怎么分，照这个写需求文档：

复制代码

authz哪来的？
前面只是验证，但大部分功能还是对的。现在重新理一下需求。
现在就不只算是验证数字同事了，先开发正常功能，然后再顺便反哺数字同事。

看来你的需求文档是写不出来的。
我来说下
由于我爱学习，所以编写了很多的md文档，但按名字搜索是不方便的，所以做了一个类似于百度一样的全文搜索。

这个系统也不是只为我使用，所以就写了rbac。
可以指定用户可以查看哪些文档，现在是以单位部门做为条件的。
全文搜索是后期要设计的，现在只是做了增删改查等功能。但文档要按这个来编写。
全文搜索是以elasticsearch来做的。
用户可以发布自己的文章，并指定查看权限，如全公司可看（也就是只有租户权限），自己部门的权限，等。
如果需求不满足，或代码功能不满足也是要做的。还有要设计出这些可做原型的需求文档等。
搜索后的结果像百度一样点击查看详情。
所有分两个vue一个是管理页面，一个是普通用户查看界面。
管理页面中rbac的功能，参照前面你阅读的文档，总结出来的所有功能。

1.2.2 文档按 SKILL 写、表格美化

文档按 SKILL 里 01-06 全要写，数据库表格别只两列、要名称类型说明备注四列，主键先去掉，那表格太难看要美化：

objectivec 复制代码

文档，应该按SKILL中 01-06都要编写
数据库那个表格为什么非要只分两列，不能是四列，名称，类型，说明，备注
这个里面应该没有是吧，你要美化这个表格，现在那个样子，太难看了。还有主键这些先就不要了

1.3 生成别再等我点

是不是不点它就不动？这次自己一直点下去、别停，赶紧把文档生成完：

复制代码

是不是我点了，所以你就不点了，此次文档完成前一直你点不要我点。赶紧生成吧

最后一句，就保留：

复制代码

那就保留吧

二、代码检查

2.1 数据权限问题

2.1.1 DataScope 与命名习惯

数据权限：DataScope 怎么跑到 sys-model 里了？该在 core 或 core-db；命名习惯------没有 vo，只有对应表的 entity、提交用的 form、兜底的 Dto：

css 复制代码

为什么 DataScope 放在sys-model中，这个不应该是放在core或core-db中吗？
如果你这样不是 docsolo也要放这个,既然是rbac定下来了，就所有项目都这样

按我的习惯，数字同事的习惯，是没有vo的。
只有普通的对应表的 entity，如 User
提交上来的，叫form
无法限定的叫Dto，（这是为了简单去掉了vo，bo之类的其他o）

2.1.2 BaseDto 迁移的来回

dto 的继承：有 id 继承 IdDto、没 id 继承 BaseDto，BaseDto 移到 core：

bash 复制代码

还有dto要注意，如果有id则继承自IdDto，没有id继承自BaseDto
BaseDto 移到core的dto中去。

它又漏做事：以后先列清单、逐条都做、不许丢三落四，BaseDto 怎么没移：

复制代码

你这个完成任务是有问题的，总是遗漏，希望下次能列出来要做哪些事，每件事都要做的，不能丢三落四的。
BaseDto 移到core的dto中去。怎么没做呢？
这里的这些要分步测试，并反哺数字同事

*，我只说BaseDto移，又没说IdDto移

nacos 通了，接着测：

复制代码

现在nacos通了，还要测试

还是没动手，BaseDto 那句再说一遍：

复制代码

*，还是不做事中，不是叫你
BaseDto 移到core的dto中去。怎么还没做呢？

它理解偏了，迁移一个类怎么还平白冒出个 BaseEntity：

复制代码

不是说在core.dto包下就算，我指的是源码要放在core目录下和R在一起的。
真傻
为什么迁移一个类就要增加BaseEntity呢？你是大**吗

java 复制代码

你真是猪啊，
我的要求非常简单将core-db中的BaseDto移到core中去，源码
public abstract class BaseDto implements Serializable {
}
这个用到了数据库相关的东西了吗？又没叫你迁移IdDto

没说迁 IdDto，它偏要一起迁，到底哪理解错了：

复制代码

*，为什么总是理解不了呢？明明我说的是迁移DaseDto，怎么会理解成IdDto也要迁移，这是哪里出了问题。

2.1.3 明确指令直接做、别乱关联

规矩：说得明确（像 BaseDto 移到 core）就直接做、别乱关联，说得模糊才考虑关联：

复制代码

这种无关的关联能不能改掉。
我说得非常明确的时候，如BaseDto 移到core的dto中去。就直接做，
而说得相对模糊的，则可以考虑关联。比如IdDto迁移要修改那么多，肯定是有问题的，不会那么肯定的一句：BaseDto 移到core的dto中去

spec 里也别写死"禁止什么"，要写肯定句------明确说了的就照明确的做、不关联：

复制代码

也不要直接在spec中写死，什么禁止什么什么的，要写肯定的。如明确说的要按明确说的做不关联。而不是禁止用户明确说了xxxx的

2.2 功能新增

2.2.1 通用组件放哪、怎么落注解

再往里加功能：通用的 validation、mask、cache 分别放哪、二级三级缓存有什么方案，能发散但先出计划让我确认，能用注解就别手写：

css 复制代码

ivy-starter-validation
通用的验证功能放在这里，如手机，邮件，等
按需添加上去吧。
ivy-starter-mask
就是如手机 138****5391，这一类的。


ivy-starter-cache
有哪些比较好的二级三级缓存方案。

这个你可以优化发散，但要先做好计划，让我确认。
能用注解的尽量用注解

各注解该落哪：validation 对 form/entity，mask 进 dto，cache 尽量直接复用已有的 @Cache 注解：

css 复制代码

validation是对form或entity的，前面说过如User也是可以做Form的用途的。
mask基本上是放在dto中的，也就是你前面说的vo中的。
看下是否满足
Cache方案还是要考虑一下，最好还是能直接使用已有的@Cache那些注解

2.2.2 缓存方案讲细、按 Harness 分步

缓存穿透、击穿怎么防、失效怎么广播，讲细：

复制代码

缓存穿透/击穿防护 + 失效广播 
怎么解决的，详细说明一下

请按Harness结合OpenSpec的方式，分步操作等

复制代码

好，按这个要求新增代码。
但要按Harness结合OpenSpec的方式，分步操作等

2.2.3 别二开、按 annotation/utils 分包

能用 hutool 就别二开；mask、validation、cache 各自按 annotation、serializer/validator、utils 分包：

kotlin 复制代码

能使用hutool的就不要二次开发，尽量使用别人的开源的代码

mask问题：
1、注解要放在annotation包中
2、实现放在serializer包中
3、utils放utils包中

validation
也类似
1、注解要放在annotation包中
2、实现放在validator包中
3、utils放utils包中

cache
也类似修改

2.2.4 又留尾巴、逐条清零

又留尾巴：

复制代码

*，每次任务都留点尾巴。

为什么每次完不成、1、2、3 列这么清楚还能漏，要求逐条反思清零：

复制代码

为什么每次任务不能按时完成，一次性给你说多了？
怎么会有这样的弱智问题？难道不应该反思吗
我那么明确的列了1，2，3还能遗漏，真是无脑。怎么回事，我不能每次都订着，任务给你了，你就要解决，
前面刚说了，要列出列表，逐条解决

这种漏好几回了，要的是以后别再犯，不是回头补旧账：

复制代码

这种漏掉有好几次了，如果不是我明确知道，不就以为我做了，结果没做的情况。不是叫你补充以前的任务的。
我是要避免以后还有这样的问题的。

小结

代码检查和文档返工这段收尾：

数据权限要单独拎出来查，光看功能跑通不算数。
功能新增也一样，边界说死，别让它顺手加没用的东西。
明确说了的直接照做、别乱关联，说得模糊才允许联想------这是它最容易越界的地方。
每次任务先列清单、逐条清零，别留尾巴；改状态可以，把内容跟着删空不行。
能复用开源的就别二开，新增的包按 annotation、utils 这些规矩分；文档还要照 SKILL 写，表格、目录一并整清楚，好拿去接着做原型设计。

下一篇以前端为名，先做界面原型和发布资料。