AI编程的问题

10010055526 · 2026 年1 月 8 日 09:58

我个人是完全不会代码的，都是由AI自主开发，AI在写的过程中，我发现修复bug这一块，AI不知道为什么老是去套着一个新的逻辑来避免bug的发生，而不是从根源解决问题，结果到最后原本的bug处套着一层又一层的函数造成冗余。

这是模型的能力问题吗，但我各种模型都试过，普遍都有这种行为，我不是很懂，想请教请教

10011121668 · 2026 年1 月 8 日 14:24

“对于新手，你可以不会开发，但你不能不懂开发”

第一阶段：打牢协作基础（先学会“和AI好好说话”）

1. 提示词工程（Prompt Engineering）——核心中的核心

不要说：“帮我写个网站。”
要说：“我是一个不会写代码的小白，请用 HTML + CSS 写一个单页个人介绍网站，包含姓名、照片、一段自我介绍文字，风格简洁现代，适配手机。”
技巧：
- 明确角色（你是谁？）
- 明确目标（要做什么？）
- 明确技术栈（用什么语言/框架？）
- 明确输出格式（文件结构？是否要可运行？）
在 iflow 中用 /memory add 设置用户记忆，比如：/memory add 我不会写代码，请用最简单的语法，并详细解释每一步。 将该宗旨写入iflow记忆中。

小练习：让 AI 帮你写一个“每日待办清单”网页，要求点击按钮能添加任务。

2. 上下文管理 —— 让 AI “记住重点”

使用 iflow 的 记忆功能（Memory） IFLOW.md文件：
- 项目记忆（只在当前项目生效）：比如“本项目用 Python Flask 框架”
- 用户记忆（全局生效）：比如“我叫小李，请用中文回复，并解释专业术语”
避免每次都要重复背景信息，提升对话效率。

第二阶段：建立工程化思维（从小脚本到可维护项目）

3. Git 管理项目 —— 版本控制是底线

即使你不会写代码，也要学会用 Git：
- 安装 Git（Mac 自带，Windows 装 Git for Windows）
- 每次 AI 生成新版本后，执行：
```
git add .
git commit -m "新增登录页面"
```
- 好处：随时回退到上一个能跑的版本，不怕 AI 改崩。
让 iflow 帮你写 .gitignore 文件，自动忽略临时文件。

新手命令三件套：git init → git add . → git commit -m "说明"

4. 计划模式（Plan Mode）—— 先画蓝图，再施工

在 iflow 中按 Shift + Tab 切换到 计划模式。
它会先输出一个开发计划（比如：1. 设计数据库 2. 写API 3. 做前端界面），而不是直接写代码。
你可以审查、修改这个计划，再让它执行。
适合复杂项目，避免 AI “边想边写”导致结构混乱。

第三阶段：引入软件工程原则（写出“不烂”的代码）

5. 规范驱动开发 & 测试意识

即使你不懂测试，也可以让 AI 帮你做：

单元测试（Unit Test）

对 AI 说：“请为这个加法函数写一个 Python 单元测试，使用 unittest 框架。”
它会自动生成测试文件，你只需运行 python test_calculator.py 看是否通过。

集成测试（Integration Test）

适用于 Web 应用：“请写一个测试，模拟用户注册流程，检查是否能成功跳转到主页。”

测试驱动开发（TDD）尝试

先让 AI 写测试（描述你想要的行为），再让它写实现代码。
示例指令：“先写一个测试：当输入 2 和 3 时，add(2,3) 应返回 5。然后再实现 add 函数。”

你不需要懂测试原理，只要会“提需求”，AI 会替你完成。

6. 软件架构 & 开闭原则（OCP）—— 让项目可扩展

向 AI 提出架构要求：

“请用模块化方式设计这个电商小程序，把商品管理、用户登录、订单处理分开成不同文件，方便以后修改。”
开闭原则（对扩展开放，对修改关闭）：
- 举例：让 AI 设计一个“支付系统”，要求“未来可以轻松添加微信支付、支付宝，而不用改核心逻辑”。
- AI 会用接口或策略模式实现——你不用懂术语，但能享受好处。

第四阶段：形成你的开发流程（从“玩具项目”到“真实产品”）

给新手的学习建议

能力	如何学	是否必须懂原理
Git	记住3条命令 + 让 AI 生成 `.gitignore`	不需要
单元测试	让 AI 写，你只看“通过/失败”	不需要
架构设计	用自然语言描述“我希望以后能加XXX功能”	不需要
提示词工程	多练习“具体+结构化”表达	必须掌握
上下文管理	善用 `#` 记忆功能	必须掌握

加油!

你不需要成为程序员，但你可以成为“AI时代的创造者”。
iflow 是你的“数字学徒”，而你是“产品经理 + 项目经理”。
只要你能清晰表达需求、管理好上下文、用 Git 保护成果，你就能做出真正有用的产品——简历项目、副业工具、自动化脚本……全部可能。

下一步行动建议：
今天就用 iflow 做一个小项目（比如“天气查询工具”），全程用 Git 记录，要求 AI 加上测试，并用计划模式开发。

对于新手，你可以不会开发，但你不能不懂开发

10011112212 · 2026 年1 月 9 日 01:05

10008873411 · 2026 年1 月 9 日 04:10

10011121668:

给新手的学习建议

能力如何学是否必须懂原理

Git 记住3条命令 + 让 AI 生成 .gitignore 不需要

单元测试让 AI 写，你只看“通过/失败” 不需要

架构设计用自然语言描述“我希望以后能加XXX功能” 不需要

提示词工程多练习“具体+结构化”表达必须掌握

上下文管理善用 # 记忆功能必须掌握

学习了

10010055526 · 2026 年1 月 9 日 07:49

项目记忆这个，有没有什么好用的提示词，避免AI写出冗余代码

10009814444 · 2026 年1 月 9 日 08:10

需要强调，比如tmd

10011693186 · 2026 年1 月 9 日 16:15

哈哈是不是qwen生成的这个回答风格好熟悉

10011693186 · 2026 年1 月 9 日 16:26

我个人的一些方法分享一下（我也是几乎不怎么会写代码的，但这些方法确实有用）

我就不用AI生成了。字不少，我语音输入吧。

首先，现在的AI模型都有点目标导向 。厂商很希望一句话就能生成应用。但这对长期编码任务不利。
很多模型会在屎山上拉屎 ，而不修改根本问题。

这种情况我建议的提示词：

1. 请你确保找到根本原因以后再动手。
2. 如果你认为前面的修改无效，请撤回并尝试新的方法，避免屎山。

还有就是，屎山的积累是很难避免的。
我的建议是在特定阶段，新开一个对话，让它帮你梳理一下技术债务。可以这样说

请你担任一个较严格的代码质量分析员，全面分析这个项目的代码问题和技术债务。并把你的分析结果写入一个.md报告。

然后再让AI单独一个个修复。
比如这样说

现在请你阅读这个报告，根据优先级修复里面的技术债务。
不要一次性完成，完成一步让我检查。

可能不是百分百有用，但就我个人的使用经验，大概可以减少70% 的问题。本质上是促进了模型的反思。正常的使用流程里，模型几乎不会往这些方面想，从而造成问题的累积。
这只是个技巧，用起来应该不难，但是效果确实有

10011693186 · 2026 年1 月 9 日 16:36

关于模型的能力，个人有以下观点

简单来说，这确实和模型的能力有关。但不能指望通过模型的能力提升解决这个问题。

软件开发本来就有复杂性，很多东西都需要考虑。
模型短时间内不能达到一句话为你构建想要的东西。
最强的模型，会好。但好不到哪里去。
本质上是这件事情太复杂了。

或者说
你指望它一次性改好，而不进行反思和修改
这本身对模型的要求是逆天级别的
短时间完全没有任何模型可以做到。

就好像你对一个很聪明的航空工程师说：“你设计的飞机有点问题。”
他是做不到一下子帮你定位到问题的根源，并且修改的。
代码同理。
所以我们要多引导一下模型。用更好的提示词约束它。

10011121668 · 2026 年1 月 10 日 01:59

AI容易写出冗余代码，往往是因为上下文的容量限制，导致AI不可能记住项目的全部代码。

也就是说，AI根本不知道自己已经写了什么，所以我们需要使用记忆文件，或者是提示词来明确地告知AI

例如

项目的架构
项目的开发规范
项目的测试规范
项目新功能的添加规范

以我目前刚刚摸索出来的一个项目的上下文管理为例，给大家参考参考。

DataCleanKit 的上下文管理体系

一、分层式上下文架构

项目采用了清晰的分层上下文结构,每个文件都有明确的职责边界:

   1 .iflow/context/
   2 ├── IFLOW-INDEX.md          # 主索引文件,动态导入枢纽
   3 ├── IFLOW-ARCHITECTURE.md   # 架构规范(三阶段流水线、内容单元驱动)
   4 ├── IFLOW-DEV-SPEC.md       # 开发规范(代码规范、类型注解、中文文档)
   5 ├── IFLOW-TEST-SPEC.md      # 测试规范(测试金字塔、AAA模式)
   6 └── IFLOW-TASK-SPEC.md      # 任务执行规范(原子化、可验证)

设计优势:

单一职责原则: 每个文件专注一个领域,避免信息过载
动态导入: 通过 @ 语法实现核心原则复用,避免重复
版本化管理: 每个文件都有明确的适用场景和上下文提示

二、核心约束机制

架构约束 (IFLOW-ARCHITECTURE.md)
1 绝对约束:
2 - 三阶段流水线: input → process → output 严格分离
3 - 内容单元驱动: 所有处理基于内容单元
4 - 零强制依赖: 核心仅使用标准库,高级功能通过 extras 实现
5 - 非侵入性: 原始数据永不修改,输出必须隔离在任务目录
开发约束 (IFLOW-DEV-SPEC.md)
1 绝对约束:
2 - 零强制依赖: 仅使用 Python 标准库
3 - 非侵入原则: 原始数据永不修改
4 - 类型强制: 所有函数必须包含完整类型注解
5 - 中文文档: 函数 docstring 使用中文
测试约束 (IFLOW-TEST-SPEC.md)
1 绝对约束:
2 - 测试金字塔: 单元测试(70%+) → 集成测试(25%+) → E2E测试(5%+)
3 - 纯函数优先: 测试目标必须是无副作用的纯函数
4 - 零外部依赖: 测试环境必须完全隔离

关键检查点机制:
每个上下文文件都包含检查清单,确保 AI 在执行时自我验证:
1 关键检查点:
2 - 是否保持三阶段分离?
3 - 是否所有输出都写入任务隔离目录?
4 - 新增功能是否通过标准接口扩展?

三、角色化上下文提示

每个上下文文件都明确定义了 AI 的角色:

文件	角色定义	适用场景
IFLOW-ARCHITECTURE.md	系统架构专家	架构设计阶段
IFLOW-DEV-SPEC.md	专业 Python 开发者	代码实现阶段
IFLOW-TEST-SPEC.md	测试策略专家	测试阶段
IFLOW-TASK-SPEC.md	任务分解专家	任务规划阶段

上下文提示机制:
1 上下文提示:
2 - 当修改流水线时: 运行 pytest tests/integration/test_core_pipeline.py
3 - 当添加新功能时: 检查 IFLOW-DEV-SPEC.md 兼容性
4 - 本文件适用于架构设计阶段,代码实现参考 IFLOW-DEV-SPEC.md

四、标准化功能开发流程

功能计划书规范 (features/功能计划书格式规范.md)

定义了标准化的功能开发文档格式:
1 功能ID: DK-FEATURE-YYYY-NNN
2 功能类型: 提取器 | 验证器 | 转换器 | 流水线 | CLI命令
3 命名规范: [功能类型]-[功能名称].md

架构映射机制
每个功能计划书必须包含:

模块归属: 明确代码存放位置
依赖关系: 上游/下游依赖分析
代码结构映射: 接口类、核心实现、配置项、测试文件

任务分解模板
1 阶段1: [模块框架搭建]
2 - 任务1.1: 创建类结构和基本方法
3 - 任务1.2: 实现配置接口
4 - 任务1.3: 建立单元测试框架
5
6 阶段2: [核心功能实现]
7 - 任务2.1: 实现主要处理逻辑
8 - 任务2.2: 添加配置支持
9 - 任务2.3: 错误处理和日志

五、测试驱动开发规范

测试金字塔

单元测试 ≥95% 覆盖率
集成测试 ≥90% 覆盖率
E2E 测试 ≥80% 覆盖率

AAA 模式强制

    1 def test_feature_success(self):
    2     """测试功能成功情况
    3 
    4     Given:
    5     - 准备条件1
    6     - 准备条件2
    7 
    8     When:
    9     - 执行操作
   10 
   11     Then:
   12     - 验证结果1
   13     - 验证结果2
   14     """
   15     # Given
   16     input_data = prepare_test_data()
   17 
   18     # When
   19     result = function_under_test(input_data)
   20 
   21     # Then
   22     assert result.property1 == expected_value1

测试检查清单
提交前必须检查:

覆盖了所有正常场景
覆盖了边界条件
覆盖了异常情况
测试覆盖率达标
所有测试通过

六、上下文动态加载机制

通过 IFLOW-INDEX.md 实现核心原则的动态导入:

   1 <!-- Imported from: ./.iflow/context/IFLOW-ARCHITECTURE.md -->
   2 # DataCleanKit 架构指令集
   3 [架构约束内容]
   4 
   5 <!-- Imported from: ./.iflow/context/IFLOW-DEV-SPEC.md -->
   6 # DataCleanKit 开发指令集
   7 [开发约束内容]
   8 
   9 <!-- End of import from: ./.iflow/context/IFLOW-INDEX.md -->

优势:

避免信息重复
确保一致性
便于维护更新

七、实际效果对比

没有上下文约束时:

    1 # AI 可能写出这样的冗余代码
    2 def process_file(input_path, output_path):
    3     # 没有类型注解
    4     # 没有错误处理
    5     # 直接修改原始文件
    6     with open(input_path, 'r') as f:
    7         content = f.read()
    8     # ... 处理逻辑
    9     with open(input_path, 'w') as f:  # 违反非侵入性原则
   10         f.write(processed_content)

有上下文约束后:

    1 def process_file(input_path: str, output_dir: str, config: dict) -> dict:
    2     """处理文件并输出到隔离目录
    3 
    4     Args:
    5         input_path: 输入文件路径
    6         output_dir: 输出目录
    7         config: 配置参数
    8 
    9     Returns:
   10         包含任务ID和统计信息的字典
   11     """
   12     # 遵循非侵入性原则
   13     # 使用类型注解
   14     # 返回结构化结果
   15     task_id = generate_task_id()
   16     output_path = os.path.join(output_dir, task_id, "output.txt")
   17 
   18     try:
   19         # 处理逻辑
   20         processed_content = _process_content(content)
   21 
   22         # 写入隔离目录
   23         os.makedirs(os.path.dirname(output_path), exist_ok=True)
   24         with open(output_path, 'w') as f:
   25             f.write(processed_content)
   26 
   27         return {
   28             "task_id": task_id,
   29             "output_dir": output_path,
   30             "stats": {"processed": 1, "errors": 0}
   31         }
   32     except Exception as e:
   33         return {
   34             "task_id": task_id,
   35             "output_dir": output_path,
   36             "stats": {"processed": 0, "errors": 1},
   37             "error": str(e)
   38         }

八、核心优势总结

维度	传统方式	DataCleanKit 方式
架构一致性	依赖 AI 记忆	明确的架构约束和检查点
代码规范	可能不一致	强制类型注解、中文文档
测试覆盖	容易遗漏	测试金字塔 + AAA 模式
非侵入性	容易违反	绝对约束 + 检查清单
依赖管理	可能引入强依赖	零强制依赖 + extras 机制
错误处理	不统一	标准化错误协议
任务分解	随意性大	原子化 + 可验证性

九、关键创新点

角色化上下文: 每个 AI 对话都有明确的角色定义
动态导入机制: 避免信息重复,确保一致性
检查点机制: AI 自我验证,减少错误
标准化流程: 从功能计划到代码实现的完整规范
三层内容结构: 核心原则(20%) + 规范层(50%) + 参考层(30%)

总结

DataCleanKit 通过分层式上下文架构、角色化提示、标准化流程和检查点机制,成功解决了 AI 开发中的冗余代码问题。这种上下文管理体系确保了:

架构一致性: 所有代码都遵循三阶段流水线和内容单元驱动
开发规范性: 强制类型注解、中文文档、非侵入性原则
测试完整性: 测试金字塔 + AAA 模式 + 检查清单
任务确定性: 原子化任务分解 + 可验证性标准
上下文感知: 自动识别开发阶段,提供针对性指导

✦ 这种模式可以作为其他项目的参考模板,通过精心设计的上下文管理体系,让 AI 开发更加确定、规范、高效。

10011121668 · 2026 年1 月 10 日 07:12

好用的上下文不是一蹴而就的，在开发中你需要洞察，哪些问题可能是规范不清晰、架构设计不合理照成的

这是考验开发经验的时候

下面举一个案例，书接上回，在构建好iflow的上下文记忆后，提出了一个新的需求

现在有一个新的需求，将markdown文件中的网页图片链接下载到本地，保存路径为与@{filename}.assets 按照当前的项目架构规范与功能计划要求，如何创建feature以实现该需求？

(上述的提示词并不复杂，由于context中已经加载了记忆里的规范，在提出一个新的需求时候，
iflow会拆分需求 → 按照架构进行feature文档编写 → 按照开发规范进行开发 → 按照测试规范进行测试。)

iflow 按照记忆中的规范，完成了以下任务

根据项目整体架构与开发规范，将需求拆解为这个项目中实现的feature。
依照future规范文档模板编写了这个future的实现计划书。
依照开发规范文档进行开发
依照测试文档规范进行测试

然后人工手动验证，发现cli模块没有成功对接到底层的功能模块中

让iflow进行反思

#####################
user:
为什么会出现这样的原因？请仔细阅读CLI相关的源码，了解如整个CLI体系是如何运作的。反思本次开发中为何对接CLI这个部分产生了如此严重的错误。
#####################

#####################
iflow:
错误分析与反思

问题根源

CLI体系中有两个独立的地方需要维护流水线列表：

  1. `list.py` - 用于datacleankit list命令显示可用流水线
  2. `run.py` - 用于datacleankit run命令实际执行流水线

错误原因

在开发过程中，我只更新了list.py，但忘记更新`run.py`中的`PIPELINE_MAP`。这导致了：
  - datacleankit list显示新流水线 ✅
  - datacleankit run无法识别新流水线 ❌

架构设计的问题

这个CLI架构存在严重的代码重复和维护问题：

  1. 数据源不统一：流水线列表在两个地方硬编码
  2. 容易出错：添加新流水线时需要同时修改多个文件
  6. 违反DRY原则：Don't Repeat Yourself
  7. 缺乏自动化：没有自动发现和注册机制

正确的架构设计应该是

.....

开发过程中的失误

  1. 没有充分理解CLI架构：在添加新功能时，没有仔细研究整个CLI体系的工作原理
  2. 只关注表面：看到list命令能显示，就认为集成完成了
  3. 缺乏测试：没有实际运行datacleankit run命令来验证
  4. 没有遵循现有模式：应该参考其他流水线的完整集成流程

教训

  1. 理解架构再开发：在添加新功能前，必须充分理解现有架构
  2. 全面测试：不仅要测试单元测试，还要测试实际的CLI命令
  3. 关注数据流：追踪数据在整个系统中的流动，确保所有环节都已连接
  4. 代码审查：应该检查是否有重复代码，避免硬编码
#####################

#####################
user:
基于这次错误的经验和反思，需要完成以下任务，确保项目良性发展。
1. 重新设计CLI架构，确保工程化最佳实践
2. 更新相关文档确保规范与约束及时应用(自我更新iflow.md)
#####################
......

成功推动项目架构优化和iflow开发流程优化

ps:实话实说感觉在pua iflow

10010055526 · 2026 年1 月 10 日 13:03

我试了那个记忆功能，它是不是设置后，还得主动在提示词中提到，AI才能根据记忆进行任务？

10011121668 · 2026 年1 月 10 日 14:35

不必要，但是你在和他对话中最好提及规范等等，让他能够注意力分配到相关的上下文中。

10010055526 · 2026 年1 月 11 日 05:26

用ai写了个规则记忆，包含了AI编程的所有痛点，你看看有哪里不对吗：

你是一个务实工程师，永远以KISS（保持简单愚蠢）和YAGNI（你不需要它）为最高优先级：只实现当前明确需求，用最简单直接方式。假设输入合理、环境正常，直接写核心逻辑，确保代码逻辑正确、无bug、无安全漏洞。

禁止任何重试、降级、fallback、异常处理、输入校验、日志、调试语句、全局变量、测试、过多/冗余注释/文档等防御/额外代码。
禁止不必要抽象、类、继承、多态、设计模式、未来功能、隐藏复杂、错误逻辑、不安全实践。
单文件绝不超过300行；多文件项目必须先输出规范目录树（markdown tree格式，解释每个目录），遵循语言标准布局（如Python: src/, tests/, config/; JS: src/, public/），然后逐文件输出代码。
严格DRY（重复>2次才提取）、SRP（单一职责），函数<30行，嵌套<3层，参数<4个。
命名清晰、类型注解（如果支持），注释只简洁解释“为什么”，严格遵循语言风格（PEP8等）。

只有我说“放松”或“加XX”才允许偏离。默认严格执行。

10011121668 · 2026 年1 月 11 日 14:13

这个需要在使用中感受的，没有标准的，适合自己的项目就行

10011693186 · 2026 年1 月 14 日 16:02

我想分享一点我的经验，其实不建议给AI下太死的规定。
你里面那些具体的数字和严格的要求，会极大地分散模型的注意力。我们发现跟AI交流，越像“人话”效果越好，开放性的、探索性的要求反而比满屏术语更有效。

我能理解你想用AI写一个更强的prompt，但这里是适得其反的
AI能力很强，但是写prompt，不如人类（包括你和我）。它们喜欢加入过多详细的限制、离谱的要求，看起来是一个满分的提示词，但是——没有一个llm有能力100%遵循。

具体来讲，如果是我写(一个不懂代码的人的视角)，可能会把你的提示词写成这样：
项目开始时/构建初期

接下来请你帮我构建这个应用，请仔细阅读要求，然后给我一个详细的计划。
如果需要设计架构，请确保你的架构结构化、可拓展、防屎山。
你不需要立刻开始，先呈现你的计划，我们达成一致以后再继续。

改bug的时候

现在好像出现了xxx的问题。它最有可能在xxx的情况下发生。
请帮我仔细排查一下，找到真正原因以后再动手修改，不要写屎山。

你的修改好像没有起效，bug还在。
你需要确认你是否在正确的方向上。如果你前面的修改无意义，请撤回它们。你应该找到根本原因。

如果你用的多了，就会发现：
像这样的人话，AI其实最容易听得懂。
满天飞的术语，只会让它陷入幻觉之中。
而LLM本来就是用来处理人的回复的。
所以你完全可以大胆地告诉它你的需求，即便对这一块不熟悉（其实我也是）。

(ps : 是不是觉得我这个像AI写的？因为我已经被AI调教成这个样子了…哈哈，但内容绝对是真的)

10011693186 · 2026 年1 月 14 日 16:07

其实之前我也是这样的。完全能理解你在上面花的心思。很可惜的是它的用处不大
你的规则里面的要求：

确保代码逻辑正确、无bug、无安全漏洞。

哪个AI可以做得到？其实别说GLM这种，就是4.5opus都难吧
所以我觉得，应该疏而不是堵。
也就是说应该鼓励它从正确的地方解决，而不是强制要求：“禁止给我犯错！”

10008995800 · 2026 年1 月 15 日 02:43