人工智能编码助手如何帮助你在无需亲自编写代码的情况下进行调试

AI编程助手在修复代码方面已经变得非常出色。

将错误代码输入到AI工具中，几秒钟内就能得到修正后的代码。当你只是想让程序正常运行时，这种功能确实非常有用。

但当你在学习编程时，还有一个问题值得思考：AI是帮助你理解了问题的本质，还是仅仅帮你解决了问题而已？

这个区别非常重要。

调试并不仅仅是为了得到能够正常运行的代码，更重要的是要了解为什么会出现错误、找出错误的根源、进行相应的修改，并验证这些修改是否真的解决了问题。

我在使用Coddy.tech这个交互式编程学习平台时深入探讨了这个问题。这个平台结合了编程练习、测试反馈、调试工具、提示功能，还配备了一个名为Bugsy的AI辅导系统。

我并没有仅仅关注AI是否能够解决某个编程问题，而是试图探究另一个问题：在AI直接给出答案之前，它应该提供多少帮助才算合适？

在这篇文章中，我将探讨这个问题，提出一个关于AI辅助调试的简单框架，并通过自己在Coddy上的实际操作来验证这些想法在实践中是否有效。

目录

• 调试并不仅仅是生成正确的代码

• 开发者们实际上是如何进行调试的

• AI辅助调试的框架

• 渐进式的帮助方式非常重要

• 我在Coddy上尝试了这个学习流程

• 转向更复杂的挑战

• 但是，多少帮助才算过度呢？

• AI并不是整个学习体系

• 编程助手应该采用不同的评估方式

• AI编程助手也需要考虑边界条件

• 评估AI编程辅助效果的实用框架

• 总结

调试并不仅仅是生成正确的代码

让我们从一个简单的Python函数开始吧：

def calculate_average(numbers):
    total = 0

    for number in numbers:
        total += number

    return total / (len(numbers) - 1)


scores = [80, 90, 70, 100]

print(calculate_average(scores))

上述程序在运行过程中没有出现任何语法错误或异常，但计算结果却是错误的。 这四个数值的总和是340，因此预期的平均值应该是： 340 / 4 = 85 但实际上，该函数计算的是： 340 / 3 原因就在于这一行代码： return total / (len(numbers) - 1) 如果使用人工智能助手，它应该可以直接给出正确的答案： return total / len(numbers) 这样问题就能得到解决。但对于正在学习编程的人来说，人工智能实际上已经替他们完成了大部分重要的推理工作。 另一种更合适的回应方式可能是：

你的逻辑计算本身是正确的，但请仔细看一下除数——在“numbers”这个列表中，实际上一共有多少个数值呢？

这样一来，开发者仍然需要自己去分析这些逻辑。这种差异其实反映了人工智能辅助编程时两种截然不同的工作方式。

开发者们究竟是如何进行调试的

当我们手动进行调试时，通常会按照这样的步骤来进行： 调试 → 分析问题原因 → 找出解决方案 → 修正代码 → 验证结果 假设有一段测试代码失败了：

assert calculate_average([80, 90, 70, 100]) == 85

我们首先会查看实际计算得到的结果，然后检查这个结果是否与预期值相符。如果总和是正确的，接下来就会验证除法运算是否正确。 最终我们会发现，这段代码其实是用四个数值来计算平均数，但却像是在处理三个数值一样进行运算。 整个调试过程其实都是在帮助我们理解代码中的问题所在。 如果使用人工智能助手直接修改代码，虽然代码看起来能够正常运行了，但其中很多重要的推理过程却消失了。这说明，那些专为学习编程而设计的人工智能辅助工具，仅仅具备代码生成功能是远远不够的；它们还需要有一种策略来决定应该提供多少帮助才合适。

人工智能辅助调试框架

我认为，可以通过五个阶段来实现这一目标： 上下文分析 → 问题诊断 → 提供提示 → 结果验证 → 原因解释 每个阶段都有其特定的作用。

1. 上下文分析

在提出解决方案之前，辅助工具首先需要了解用户真正想要实现的目标是什么。 这些上下文信息可能包括：

• 需求或问题描述

• 当前的代码代码

• 预期的输出结果

• 实际计算得到的结果

• 编译器或运行时出现的错误

• 那些失败的测试用例

• 之前尝试过的解决方法

如果没有这些信息，即使给出的建议在技术上是正确的，也可能并不符合实际的需求。 举个例子：

def is_adult(age):
    return age > 18

这种实现方式是否正确呢？我们无从判断。 如果需求明确要求一个人的年龄必须大于18岁，那么这种实现方式就是正确的。 但如果是要求一个人在年满18岁时才被视为成年人，那么这段代码就存在边界条件错误了。这段代码本身并不包含足够的信息来做出这样的判断。而需求描述则提供了缺失的上下文信息。

2. 诊断

一旦获得了足够的上下文信息，辅助系统就能确定问题可能出在哪些地方。

诊断的目的应该是说明到底哪里出了问题，并不一定要指出应该用哪段代码来替换有问题的那段代码。

以我们举的例子来说，人工智能助手可以这样回答：

总和的计算结果是正确的，但用于除法的元素数量与列表中值的数量并不一致。

这样的诊断虽然不能完全解决问题，但至少能缩小问题的范围。

3. 提示

如果诊断还不够，辅助系统还可以提供更具体的提示，比如：

先检查`len(numbers)`对于这个输入样本返回的值，然后将其与你代码中的除数进行比较。

现在你有了一个明确的调试步骤，但仍然需要继续进行修改。

这种帮助方式就像是一级级逐步提供的提示：

观察问题 → 提供方向 → 给出更具体的提示 → 解释原因 → 找到解决方案

人工智能辅助系统并不一定非得采取二分法来提供帮助；在完全不提供任何帮助和直接揭示全部逻辑/实现细节之间，还有许多有用的中间层次。

4. 验证

仅仅修复了错误还不够。

在修改代码后，你可以进行如下测试：

assert calculate_average([80, 90, 70, 100]) == 85

assert calculate_average([10, 20]) == 15

assert calculate_average([5]) == 5

看起来一切正常。

但再试一次：

calculate_average([])

现在又出现了另一个问题：除以零的情况。

虽然原来的错误已经得到了修复，但验证过程揭示了另一个你之前没有考虑到的情况。

任何有用的人工智能辅助系统都不应该仅仅帮助你让某个出错的例子恢复正常运行，而应该鼓励你去思考还有哪些其他情况也可能会导致问题发生。

5. 解释原因

在找到解决方案之后，人工智能可以帮助你加深对这一概念的理解：

平均值的计算方法是将总和除以元素的数量。因为这个列表一共有四个元素，所以从列表长度中减去1后，实际上就是用总和除以3而不是4。

在这个阶段，解释的作用是帮助你巩固理解，而不是替代你的思考过程。

逐步提供的帮助非常重要

想象一下，有人正在实现这样一个需求：一个人在18岁或以上时就被视为成年人。

他们编写了这样的代码：

def is_adult(age):

    return age > 18

如果人工智能辅导系统不立即将`>`替换为`>=`，而是逐步提供帮助，那么第一个提示可能会是：

请检查你的边界条件设置。

如果学习者仍然遇到困难：

当年龄恰好为18岁时，应该发生什么情况呢？

接着还需要注意：

你目前的比较方式实际上忽略了边界值本身。

只有在必要时，辅助系统才会最终提示：返回“年龄 >= 18”。

与传统的“问题 → 人工智能 → 答案”模式不同，这里的流程是“问题 → 观察 → 提示 → 推理 → 尝试 → 验证 → 解释”。

这种学习体验确实截然不同。

我在Coddy中尝试了这个学习循环

我想看看这些教学理念在实际的编程学习环境中会如何体现，因此我在Coddy.tech上进行了实验。

我从一个针对初学者的Python练习开始——这个练习与行注释有关。

任务要求很简单：在不删除任何代码的情况下，在“print("Goodbye!")”这一行前添加注释符号，这样下面的代码就能正常执行：

Hello, Python!

从编程的角度来看，这个练习本身并不特别有趣。真正吸引我的是围绕这段代码所提供的各种功能。

在同一个工作空间中，我可以查看任务要求、基于浏览器的Python编辑器、运行代码的功能、测试结果、预期输出、多种提示信息、解决方案的获取途径，还可以解释这个练习的含义，此外还能使用Coddy的人工智能导师Bugsy来帮助学习。

这样的设计为学习者提供了多种应对失败的方式，而不必直接求助于人工智能系统来获得答案。

在人工智能提供帮助之前先进行测试反馈

我故意输入了一个错误的解决方案，然后运行了代码。

Coddy的测试系统会将我的错误与任务要求联系起来，告诉我需要在“Goodbye!”这一行的开头添加注释符号，而不要删除这条代码。

预期输出结果也会被显示出来：

Hello, Python!

从测试的角度来看，这种设计非常有用——虽然看起来很简单，但学习者并不会只关心“代码能否成功执行”，他们还会思考“这样的实现是否能够达到练习要求的效果”。

这两个问题是不同的。一个程序可能运行成功，但其功能却可能存在错误。

通过展示预期的输出结果，可以让学生尽早认识到这一点。

逐步提供的提示信息

同一个练习还提供了不同级别的提示信息。

最初的提示让我知道需要在相应代码行的开头添加“#”符号，之后还会有更多的提示可供参考。

这就形成了另一种学习路径：尝试 → 测试反馈 → 提示1 → 提示2 → 提示3 → 解决方案。

学习者并不一定需要直接从失败的状态跳到正确的答案。这种设计正好符合我们之前讨论过的渐进式辅助教学模式。

用错误的代码测试Bugsy

接下来，我在编辑器中仍然保留着那段错误的代码，然后打开了Bugsy。

这样得到的结果反而更有意思。

Bugsy理解了这项练习的目的，并提示我应该将“Goodbye”这一行注释掉。

但它同时也发现了我的代码中存在的另一个问题：即“Hello”这句话的引号或括号使用有误。

第二个问题其实更为重要，因为这并不仅仅与练习所教授的概念有关，而是直接源于我实际编写的代码。显然，Bugsy是在同时考虑练习的要求以及我在编辑器中输入的内容来给出反馈的。

这就说明了为什么“上下文”是这个学习框架中的第一个要素：上下文 → 诊断 → 提示 → 验证 → 解释

现在我们来看看这段与练习无关的代码：

print("Goodbye!") 

print("Hello, Python!") 

从表面上看，这段代码并没有什么问题。

只有当我们了解到某些特定的背景信息后，才能意识到“Goodbye!”这一行不应该出现在代码中，而且应该将其注释掉而不是直接删除它。

正是在这种情况下，AI技术在学习环境中的作用就显得尤为重要了。

将帮助与解决方案区分开来

另一个让我觉得有趣的细节是：Bugsy在提供指导的同时，始终将“显示解决方案”这一选项保留为独立的操作选项。

这种设计有效地区分了帮助我继续前进和直接给出答案这两种功能。

虽然这种区分可能并不十分完美（我们后面还会讨论这个问题），但我很欣赏这种设计理念。

AI辅导系统并不一定需要将每一个求助请求都理解为要求直接展示完整的实现代码。

find_book_descriptions(catalog, query)

这个函数需要在一个二维的图书目录中进行搜索。

每本书都包含一个ID和描述信息。

实现过程需要包括以下步骤：

• 遍历所有的书籍记录

• 进行不区分大小写的匹配操作

• 同时搜索书籍的ID和描述信息

• 收集所有匹配的结果

• 使用换行符将所有的结果连接在一起

• 如果没有找到任何匹配项，返回"没有找到相关的书籍。

这为我测试该辅助功能提供了更加理想的环境。

我故意编写了一个包含Python代码与伪代码的“有缺陷”的实现版本。

当我运行它时，很多测试用例都出现了失败结果。

这些测试用例不仅能显示失败结果，还能展示程序的实际运行行为。

测试界面会同时显示多个测试用例、输入参数、程序实际输出以及预期输出结果，这一点非常重要。

你不仅能看到“失败”信息，还可以深入分析“输入 → 实际运行结果 → 预期结果”之间的关联关系。

这才是真正的测试流程啊。

即使有一个测试用例通过了，也不意味着整个实现方案就满足了所有要求——不同的输入条件可能会暴露出不同的缺陷。

在不立即求助于AI的情况下进行调试

对于这个案例，系统还提供了专门的“调试”功能，我利用它来分析那个有缺陷的实现版本。

系统并没有要求我修复整个程序或详细解释代码逻辑，而是直接指出了Python代码中出现的错误：

SyntaxError: 语法错误（main.py文件，第5行）

我觉得这种分离设计很有意义——并不是所有的编程问题都需要借助生成式AI来解决。

如果Python本身已经能定位出语法错误的位置，那么直接提供这些信息就足以让你自行进行排查了。

到这个时候，我已经拥有了三种不同的反馈机制：

反馈机制	它能帮助解答哪些问题？
测试用例	我的实现是否符合预期效果？
调试工具	程序当前在哪个环节出现了故障？
Bugsy	我的设计方法可能存在哪些问题？该如何改进？

然后我询问了Bugsy

我把那个有缺陷的实现版本提交给了Bugsy。

这一次，它的反馈内容远远超出了仅仅指出语法错误的范围——它清楚地识别出我的代码中同时使用了Python和伪代码这一点。

它还为我指出了几处需要修改的地方，比如：为描述信息创建列表、遍历每一本书的数据、将书ID与描述内容分开处理、使用小写字母进行不区分大小写的搜索操作，以及应该将描述内容添加到结果中而不是查询条件中。

它还揭示了一个更为有趣的控制流问题。

当系统仍在搜索个别书籍时，不应该出现“未找到任何书籍”的提示。为什么呢？

假设第一本书不符合要求，但第二本书符合，那么如果程序在尚未遍历完整个目录时就得出“未找到任何书籍”的结论，这个判断可能是有失偏颇的。

这不仅仅是语法上的修正问题，还需要我们理解需求与控制流之间的关系。

在这种情况下，基于上下文的AI辅助就比单纯的错误提示要有用得多。

但是，多少帮助才算过多呢？

这个中等难度的案例也暴露出了一个局限性，或者至少是一个重要的权衡因素。

Bugsy在识别出问题所在后，并没有就此停止工作，而是提供了相当详细的实现步骤，说明了该如何完成这项任务。

从提高工作效率的角度来看，这确实非常有用。如果我是一名经验丰富的开发者，想要快速完成任务，这样的帮助对我来说非常有价值。

但如果你只是想了解某个概念，那么更多的信息并不一定总是有用的。

下面来看看这两种不同的回应方式。

方法A

这是经过修改后的实现代码……

方法B

在您仍在搜索目录时，“未找到任何书籍”的条件就已经被评估了。

如果第一本书不符合要求，但第二本书符合，这两种方法最终都可能产生正确的代码结果。

不过方法B要求使用者必须思考控制流的逻辑。

这对AI辅助系统来说确实是一个难题。

AI辅助系统通常有两个目标：

帮助学习者成功完成任务

以及

保持足够的难度，促使学习者进行思考

这两个目标有时会发生冲突。

即使AI辅助系统能够生成完整的解决方案，它仍然需要判断这样做是否真的最有帮助。

不同的学习者可能需要不同程度的帮助

合适的帮助程度也取决于求助者的需求。

初次学习循环结构的新手可能会从逐步引导中受益，而经验丰富的开发者在调试不熟悉的库功能时，可能只想要得到直接的答案。

因此，理想的交互方式也许并不总是：“这是解决问题的方法。”

它应该首先了解用户的真实需求：

您是需要提示、解释，还是需要修改后的代码实现？

这是一个相对简单的用户体验决策，但它会改变AI辅助系统的作用和角色。

AI并不是整个学习体系

在进一步探索Coddy的过程中，我意识到：Bugsy并不是唯一的学习工具。

该平台还将各种学习活动划分为“学习旅程”、“实践练习”、“项目制作”和“任务挑战”等不同领域。

在我参与的Python学习项目中，课程内容是按照既定的教学大纲和循序渐进的学习路径来组织的。

该界面还包含了经验值、等级系统、连续成功挑战机制、每日任务以及排行榜等功能。

这些功能听起来更像是游戏化的设计，而非人工智能技术。但正因为如此，它们才值得我们深入探讨。

学习编程需要反复练习，并且需要得到适当的鼓励，这样才能让学习过程变得有趣且富有成效。

人工智能确实可以解释为什么某个循环会出错，但仅仅理解了这种解释，并不意味着你明天就能正确地实现另一个类似的循环。

你仍然需要通过实践来巩固所学知识。因此，这两种系统其实是相辅相成的。

1. 学习进程：学习旅程 → 实践练习 → 项目制作 → 反复练习

2. 遇到问题时的辅助机制：运行代码 → 测试反馈 → 调试提示 → 错误排查 → 解决方案

我认为，在评估人工智能学习产品时，这种区分是非常重要的。

我们不应该只关注人工智能本身的能力有多强，还应该思考：在学习过程中，使用者在请求人工智能帮助之前和之后做了什么？他们是通过使用这些技术巩固了自己的基础知识，还是变得更加依赖它们了呢？

编码助手应采用不同的评估标准

大多数针对编码助手的评估都会自然地关注它们是否能够生成正确的代码，这一点确实很重要。

但对于那些旨在辅助学习的人工智能系统来说，我认为我们还需要设计一些额外的测试案例。

例如：

测试场景	需要评估的内容
语法错误	它能否正确找到问题所在？
运行时错误	它能否解释执行失败的原因？
逻辑错误	它能否在不重新编写代码的情况下诊断出问题？
边界条件测试	它是否能够理解诸如0、空输入或等值边界这类特殊情况？
使用错误的算法	它能否引导学习者找到正确的解决方法？
多次尝试失败的情况	辅助系统是否会做出相应的调整？
代码实现正确的情况	它能否判断出代码已经没有需要修改的地方？
其他有效的实现方式	它是否能够接受与参考答案不同的解决方案？

最后两条测试场景尤其值得关注。

正确的代码同样属于测试范围

请考虑以下例子：

def square(number):
    return number * number

假设这种实现完全符合要求。

但如果我还是向人工智能寻求帮助，会发生什么呢？

一个能力较差的助手可能会因为觉得有责任给出某种答案，而建议进行不必要的修改。

而一个更优秀的助手应该能够这样回答：

你的实现已经满足了既定的要求。

这一点与我们在测试生成式人工智能系统时遇到的“误报”现象密切相关。

提供帮助并不总是意味着要找出错误；有时候，真正的帮助在于意识到其实没有什么需要修改的地方。

替代方案同样重要

编程问题也极少只有唯一一种正确的实现方式。

再举个例子：

def is_even(number):

    return number % 2 == 0

有人可能会这样写：

def is_even(number): if number % 2 == 0: return True return False

第一种写法更简洁，但两种方式都符合要求。

人工智能学习助手不应该将与参考答案不同的实现方式误认为是错误的答案。

这对任何编程学习系统来说都是一个重要的测试标准。

多次失败也是另一种测试方式

假设学习者在得到提示后，又提交了一个错误的解决方案。

这时应该怎么做呢？重复给出同样的提示可能没有帮助；而直接告诉他们完整的答案又可能过于直接了当。

相反，辅助建议应该逐渐变得更加具体和有针对性。

例如：

尝试 1

仔细看看你用来判断数字是否为偶数的那个操作。

尝试 2

除法运算会得到商，那么哪个运算能告诉你余数呢？

尝试 3

在 Python 中，% 运算符可以用来获取除法后的余数。试着用它来计算 2 除以某个数。

对于人工智能辅导系统来说，这种评估方式非常有趣——因为评价标准不仅包括正确性，还包括其适应能力。

在这个例子中，第二次请求得到了对同一个问题的另一种解释方式，同时也指出了我当前代码中的错误之处。

<这就引出了另一个值得探讨的问题：对于重复提出的请求，是应该再次提供相同的解释，还是应该根据学习者之前的互动情况来调整所提供的帮助程度？>

AI编码助手也存在边界条件

传统的软件测试会花费大量时间来研究各种边界情况。

• 当输入值为零时会发生什么？

• 当输入值达到最大值时会发生什么？

• 当输入为空时会发生什么？

• 在临界点处具体会出现什么情况？

AI编码助手同样存在边界条件，但其中许多边界条件是与其行为相关的。

• 在助手开始进行猜测之前，我们能提供多少相关信息？

• 在它实际上暴露出解题思路之前，能够提供多大的帮助？

• 什么时候提示应该变成详细的解释？

• 什么时候解释应该转化成具体的代码？

• 在多次失败之后会发生什么？

• 当学习者提出了另一种但同样有效的实现方式时，会怎样？

那么，什么时候AI应该直接回答“我目前还没有足够的信息”呢？

这些问题不仅仅是教育学上的问题，它们也是质量工程方面的问题。

评估AI编码辅助功能的实用框架

经过这些实验后，我再次回顾了之前提到的五个阶段：

1. 上下文理解：助手是否真正理解开发者的目标是什么？

2. 问题诊断：它能否找出当前实现方式为何会失败的原因？

3. 提示功能：它能否在不过早暴露完整解决方案的情况下提供足够的指导方向？

4. 验证机制：该环境是否有助于开发者验证修改后的代码在其他场景下的表现？

5. 解释说明：这种交互方式是否能帮助开发者理解最终实现的原理？

综合来看：

上下文理解 → 问题诊断 → 提示指导 → 验证结果 → 原理解释

如果一个编码助手能在这些方面表现出色，那么它所做的就不仅仅是生成代码，它还在积极参与调试过程。

Coddy的应用场景

这就是为什么我觉得研究Coddy很有意义。它的最吸引人的地方并不在于它拥有AI助手这一功能。

如今，AI几乎可以应用于任何编码工具中。事实上，不仅限于编码工具，几乎所有领域都可以运用AI技术。

而真正有趣的组合是：结构化学习 + 编码练习 + 可执行代码 + 测试反馈 + 调试功能 + 基于上下文的AI辅助。

每个组成部分都有其特定的作用：

1. 结构化学习：为学习者提供明确的方向。
2. 编码练习：帮助学习者将理论知识应用到实际操作中。
3. 可执行代码：让学习者能够立即看到自己的代码运行结果。
4. 测试案例：用于对比实际实现与预期效果。
5. 调试功能：帮助学习者发现并解决技术问题。
6. AI辅助：提供逐步的指导和支持。

这些元素共同作用，才能让AI编码助手真正发挥出价值。

Bugsy能够提供额外的上下文相关指导，而完整的解决方案则代表着更高层次的辅助作用。

在我尝试过的那些练习中，所形成的工作流程更接近于以下顺序：

学习 → 编写代码 → 运行代码 → 发现错误 → 检查问题 → 调试代码 → 寻求帮助 → 重新尝试

而不是：

遇到问题 → 向AI求助 → 复制答案

这种差异其实非常重要。

同时，我的实验也表明，具备上下文理解能力的AI仍然能够迅速提供大量的实现指导。

AI应该披露多少信息，以及何时披露这些信息，这些都是重要的设计考量因素。

减少AI的使用并不总是我们的目标。这并不意味着开发者应该避免使用AI生成的代码，在很多情况下，立即生成实现代码正是我们所需要的。

经验丰富的工程师可以利用AI来：

• 生成样板代码

• 创建单元测试用例

• 优化重复出现的代码段

• 理解不熟悉的编程库

• 快速搭建实现原型

• 解释那些陈旧的代码逻辑

• 编写文档资料

在这些情况下，速度往往是最重要的考虑因素。

但请对比以下两种请求：

帮我完成这个代码实现。

与：

帮我弄清楚为什么我的代码会出错。

虽然它们可能使用的是完全相同的代码，但所追求的目标却截然不同。一个优秀的AI编码助手应该能够区分这些差异。

总结

最令人印象深刻的AI编码助手并不一定是那个生成最多代码的助手，有时候，它反而会是那个知道何时不应该生成代码的助手。

一个好的调试辅助工具应该能够帮助开发者从以下状态转变为：

“我的代码无法正常运行。”

到：

“我明白了为什么我的代码会出错。”

要做到这一点，仅仅生成代码是远远不够的。

它还需要提供上下文信息、诊断分析、逐步指导、验证结果以及详细的解释。

我对Coddy的实验表明，将AI与编码环境相结合确实能够带来很多好处：Bugsy既能针对具体的练习任务做出响应，也能对我正在编写的代码提供帮助，而测试用例、调试提示以及解决方案的获取途径则能提供不同层次的辅助支持。

但这也引出了一个更棘手的问题：当AI已经掌握了解决问题的方法时，它应该披露多少这些信息呢？

随着AI在编程教育中扮演的角色越来越重要，评估某个辅助工具是否能够生成正确的代码仍然会是一个重要的标准。

但我们还应该考虑另一个更为关键的问题：通过使用这个辅助工具，开发者是否对问题的理解比使用之前更加深入了呢？

对于一个AI辅导工具来说，最终衡量它的价值可能就是看它能否帮助开发者真正提高他们的编程能力。

如果你想尝试本文中提到的这些功能，可以在Coddy.tech网站上进行探索。