docs: update for toc design

src/SUMMARY.md

@@ -2,7 +2,7 @@
 
 - [前言](./prelude.md)
     - [Contributors](misc/contributors.md)
-    - [FAQ](./faq.md)
+    - [FAQ](./misc/faq.md)
 - [程序员的 AI 2.0 新机遇](./future-ai-2.0.md)
     - [思考未来的编程范式](./future-architecture.md)
     - [实时软件生成](./future-realtime-software-generation.md)

src/future-architecture.md

@@ -1,12 +1,12 @@
-# 思考未来的编程范式 
+## 思考未来的编程范式 
 
 在尝试了 ChatGPT 和 Copilot 之后，我们尝试去思考未来的编程范式应该是怎样的？
 
-## AI 代码生成：代码还应该存储在代码库吗？
+### AI 代码生成：代码还应该存储在代码库吗？
 
 对于 AI 代码生成来说，除了过去的 GitHub Copilot、Codex、Kite、TabNine 等等，新出的免费的 ChatGPT 又让人感觉非常酷。
 
-### ChatGPT 代码生成
+#### ChatGPT 代码生成
 
 现在，大家几乎已经习惯了网上的各种暴力 AI 美学 —— 唤出 ChatGPT 写代码：
 
@@ -16,7 +16,7 @@
 
 基于于在最新的 GPT 4.0 里，可以根据图片等一些基本的描述，生成全新的 HTML。
 
-### GitHub Copilot
+#### GitHub Copilot
 
 对于，我来说，作为一个开源挖坑专家，我更习惯使用 GitHub 赠送的 Copilot，只需要配合注释、输入、输出、函数名，就可以大力了出奇迹。如下是 ClickPrompt 中的真实代码：
 
@@ -28,7 +28,7 @@
 
 我在代码中保留了这个注释，一种很神奇的用法 。
 
-### 读者思考 1：Prompt 即是代码，代码不再是代码？
+#### 读者思考 1：Prompt 即是代码，代码不再是代码？
 
 因此，我觉得在 AI 编程时代，人们的编程思维是要发生变化的：
 
@@ -37,11 +37,11 @@
 
 当注释作为 prompt 保存，那么 prompt 便是作为一种代码，保存在代码库中了。而代码还将是代码吗？我们为什么还需要中间生存的代码，是因为审计、安全等原因吗？
 
-## AI 编程：写个 “真实世界” 的代码
+### AI 编程：写个 “真实世界” 的代码
 
 而当你尝试过使用 AI 来编写代码之后，你会发现 AI 存在一系列所谓的 “问题” 。让我们来再看一个简单的例子，我们让 ChatGPT 来实现一段代码。
 
-### ChatGPT 编程：AI 实现一个 API `/book/:id` 的 N 种方式
+#### ChatGPT 编程：AI 实现一个 API `/book/:id` 的 N 种方式
 
 在不同的语言和架构模式里，实现的方式是有区别的。
 
@@ -98,7 +98,7 @@ exports.handler = async (event, context) => {
 
 然后，我们就可以采用 ClickPrompt 类似的方式，直接一键部署到服务器之上。
 
-### 对比一下：上面的三种方式各有什么优缺点？
+#### 对比一下：上面的三种方式各有什么优缺点？
 
 让 AI 来对比一下，你看吧，显然 AI 也觉得 Java 的实现起来复杂，但是可扩展性高。
 
@@ -114,41 +114,41 @@ exports.handler = async (event, context) => {
 
 但是，我们真的需要所谓的可扩展性吗？而论部署速度，自然是 AWS Lambda 最快了。经过了几种不同的方式对比，按现有的软件工程来说，Java 写的代码是最好的。可是，AI 都来写代码了，Java 工程化，真的还是最好的吗？
 
-### 读者思考 2：现有的编程体系适合于 AI 编程吗？
+#### 读者思考 2：现有的编程体系适合于 AI 编程吗？
 
 让我们再打开一下思路，我们现有的架构模式、软件工程等软件开发流程都是基于现有的体系磨合过来的。
 
 而 AI 编程的最终目标是实现自动化编程，即由 AI 根据用户的需求和设计，自动生成完整的代码。但是，理论上这不是终点，终点是生成完就可以直接运行。这就意味着，一个想法从想到到上线，可能就在**几分钟内可以完成**。
 
 然而，在现有的流程里，完全不是行不通的，我们人类做不到这么的敏捷。
 
-## 全 AI 生成的新架构模式？
+### 全 AI 生成的新架构模式？
 
 过去，我们认为分层架构很重要，因为代码是人来编写，代码是人来维护的。而当代码由 AI 来编写，由 AI 来维护的话，那么现有的软件架构体系还适用吗？
 
-### 分层架构？编程范式还重要吗？
+#### 分层架构？编程范式还重要吗？
 
 尽管，我尝试让 New Bing / ChatGPT 来回答这个问题，但是，由于他们还没有 **涌现** 能力，所以只会说：程序员还需要学习和运用分层架构和编程范式，才能发挥出 AI 的最大潜力。
 
 但是，我觉得，从上面的 Java 示例中，你会发现按现有的模式构建的软件架构，特别容易发生冲突。AI 生成的 A 功能和 B 功能，可能在代码上出现重复 —— 因为上下文限制，我们不可能上传所有的代码。
 
 结果，有一天你发现了，一个类里有 10 个重复代码段。然后，你又开发了一个自动重构机器人……。但是，我觉得有点多余了，AI 编程需要新的架构范式。
 
-### AI 构建自动化软件架构？
+#### AI 构建自动化软件架构？
 
 再再打开一下思路，试着忘记现有的软件架构模式。一个功能对应一个可运行的代码段，由 AI 来自动思考架构模式 ——  当然，我们需要给他一些限制条件和输入。
 
 所以，放在当前的上下文之下，Serverless 是一种更适合的架构模式，即写即上线，即下线即删除。
 
-### 读者思考 3：Serverless 会是结合 AI 编程的答案吗？
+#### 读者思考 3：Serverless 会是结合 AI 编程的答案吗？
 
 我觉得不一定是，但是可能是当前最好的一种方案。但是，每个人都会有自己的看法。
 
-## 真实世界 2：产品经理 —— 现在，变更一个需求
+### 真实世界 2：产品经理 —— 现在，变更一个需求
 
 现在，我们来变更一个需求吧，过滤一下 “名书”，包含 xx 的不显示。那么，这个时候，我们就遇到一个难题了 —— 全自动编程，还是 **AI 辅助生成**。
 
-### 两种思路：新生成代码，还是手动改代码？
+#### 两种思路：新生成代码，还是手动改代码？
 
 纯 AI 编程，意味着：**每次改需求都重新生成代码**；而半 AI 编程，则意味着：**人可以介入到流程中**。两种将会带来不一样的思路。
 
@@ -167,7 +167,7 @@ exports.handler = async (event, context) => {
 
 所以，在这个时候，如何更好地管理原始需求，变成了一个新的挑战。
 
-### 读者思考 4：需求详细化会成为你的新瓶颈吗？
+#### 读者思考 4：需求详细化会成为你的新瓶颈吗？
 
 当我们认定 AI 能完成编码时，那么需要给详细的需求，才能确保生成的代码是正确的，诸如于：****密码长度不能小于八位，且必须同时包含字母数字和特殊符合****。这只是一个示例，更常见的示例还有表单联动：A 字段 xxx，B 字段则 xx。只有我们的需求足够的清楚，那么生成的代码才会准确。
 
@@ -180,11 +180,11 @@ exports.handler = async (event, context) => {
 
 不过，这只是用来搞笑的，我们的下一个挑战还在于需求详细化之后，AI 真的能写对吗？
 
-## 未来：自动化编程的演进
+### 未来：自动化编程的演进
 
 最后，再让我们尝试做一些思考。
 
-### AI 编程的局限性
+#### AI 编程的局限性
 
 所以，如同 AI 提炼了我的观点，AI 编程存在一定的局限性：
 
@@ -195,20 +195,20 @@ exports.handler = async (event, context) => {
 
 而你发现没有，New Bing 提炼出来的这些局限性，并不是 AI 的问题，而是人的问题。
 
-### 精准代码生成：详尽的需求的可能性？
+#### 精准代码生成：详尽的需求的可能性？
 
 我们还得考虑的一点是：
 
 尽管，提供更详尽的 prompt 可以帮助 AI 更准确地理解需求，并且避免一些歧义或误解。但是，过于复杂或冗长的 prompt 也可能导致 AI 的困惑或失效。
 
 所以，如何根据 AI 的特点和目标，选择合适的 prompt 长度和格式，以达到最佳的效果？
 
-### AI 审计 AI：解决 AI 生成代码的部分局限？
+#### AI 审计 AI：解决 AI 生成代码的部分局限？
 
 当涉及到由AI生成的代码时，有时候我们可能需要对其进行审查以确保其合规。而人工是耗时费力的，而且容易出错。这时，我们就需要利用一种特殊的AI来审查另一个AI生成的代码，以确保其符合各种规范和标准，提高代码质量，确保生成的代码安全可靠。
 
 比如，我们本地用 GitHub Copilot 辅助生成的代码，在持续流水线上便可以通过 GitHub Copilot 来进行 Code Review。
 
-## 其它
+### 其它
 
 值得注意的是：AI 编程可能会带来一些问题，如让程序员过度依赖工具、忽略代码的合理性、涉及道德和法律问题以及存在技术和人工智能之间的冲突。

src/future-realtime-software-generation.md

@@ -1,10 +1,10 @@
-# 实时软件生成
+## 实时软件生成
 
 传统的软件生成方式需要程序员编写大量的代码，然后进行测试、发布等一系列繁琐的流程。而实时生成技术则是借助人工智能技术，让计算机自动生成代码，并直接运行，从而大大提高了软件生成的效率和质量。
 
 而实时生成技术是一种借助人工智能技术让计算机自动生成代码，并直接运行的方法，大大提高了软件生成的效率和质量。实现实时软件生成的一种方式是 Prompt 编程，可以将自然语言转化为直接运行的软件，而无需生成中间的一次性过渡代码。
 
-## 引子
+### 引子
 
 从 2019 年，写了那篇《[无代码编程](**[https://zhuanlan.zhihu.com/p/61288928](https://zhuanlan.zhihu.com/p/61288928))》开始，我也一直在思考，诸如于 [2021 年]([https://www.phodal.com/blog/frontend-strategy-2021/](https://www.phodal.com/blog/frontend-strategy-2021/)) 和 [2022 年]([https://www.phodal.com/blog/frontend-strategy-2023/](https://www.phodal.com/blog/frontend-strategy-2023/)) 的前端趋势总结。
 
@@ -18,7 +18,7 @@
 
 而随着 ChatGPT 的进一步普及，你会发现你可以很容易将需求转化为**形式化格式**，进而转化而软件，从而使得软件开发的效率和速度大大提升。这种一次性代码的新型软件工程方法就是**实时软件生成**，便可以进入真正的 “**无代码**” 时代。
 
-## Prompt 编程：真正的无代码
+### Prompt 编程：真正的无代码
 
 - Prompt 编程是实现实时软件生成的一种方式，可以将自然语言转化为直接运行的软件，而无需生成中间的一次性过渡代码。每当需要运行程序时，只需要再运行一下 prompt 或者**触发词**，就可以直接运行起某个软件。
 
@@ -32,7 +32,7 @@
 
 这种一次性代码的新型软件工程方法可以进入真正的 “无代码” 时代。
 
-### Prompt 编程特性 1：从需求到代码的直接转换
+#### Prompt 编程特性 1：从需求到代码的直接转换
 
 用户只需要简单输入自己的需求就能够生成符合要求的软件，无需具备专业的编程技能。示例：
 
@@ -66,7 +66,7 @@
 
 这个例子已经相当的自由，我们也不关心中间的处理逻辑，只关注于结果。
 
-### Prompt 编程特性 2：代码只是临时产物
+#### Prompt 编程特性 2：代码只是临时产物
 
 还记得在 [Prompt 编写模式]([https://github.com/phodal/prompt-patterns](https://github.com/phodal/prompt-patterns)) 中的 `wula` 游的例子吗？在 wula 游戏里，用户只需要输入问题，ChatGPT 便会自动给出代码、代码解释和文章。诸如于：`wula: 头共10，足共28，鸡兔各几只？`，那么  AI 便会开始自动开始二次编程：
 
@@ -102,7 +102,7 @@ function calcAnimals(heads, legs) {
 
 而在复杂的场景之下，Prompt 编写需要足够的形式化，才能让机器理解，也因此，我才把它称为 Prompt 编程。
 
-### Prompt 编程特性 3：次序化的分解框架
+#### Prompt 编程特性 3：次序化的分解框架
 
 仅就当前而言 AI 的上下文能力，限制了 AI 解决复杂问题的能力。所以，它无法**一次性解决**复杂、中大型的问题，甚至于小型项目都存在一定的难度。同样的，对于人类来说，也存在这样的局限性，只是人类的问题是**领域知识有限**。
 
@@ -147,7 +147,7 @@ ddd 第二步：场景过程分析。下面是每个场景的过程分析：
 
 也可以生成代码，甚至于在上下文足够强大的时候，也是能够直接运行和自动优化的。
 
-### Prompt 编程特性 4：语言即语言
+#### Prompt 编程特性 4：语言即语言
 
 DSL（领域特定语言）是指专门针对某个特定领域的语言，通常具有严格定义的语法和规则，并且可以用来描述该领域中的问题、概念、过程和数据等。而经过形式化处理的自然语言可以被视为一种 DSL，因为它们具有明确定义的语法和规则，可以用来描述特定领域中的问题、概念、过程和数据等。