我让 AI 写了一个月的大部分代码，结果如何。

I’m happy to translate the article for you, but I’ll need the actual text of the post (the body content you’d like translated). Could you please paste the article’s text here? Once you provide it, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown, and any code blocks or URLs.

它是无辜开始的

我盯着空白的编辑器，想要构建一个简单的 CLI 工具——这本应该最多几天就能完成。但你也知道会怎样：Stack Overflow 的无底洞，像法律条文一样的文档，不断在 “我在做什么？” 与 “我到底该怎么做？” 之间切换。

于是我做了我们很多人现在都会做的事：启动了一个 AI 助手。

Prompt: “用 Go 语言编写一个 CLI 工具，接受端口号并杀死该端口上运行的任何进程。”

几分钟后，我得到了 可运行的代码。它不仅能运行——而且很精致：错误处理、友好的提示信息、跨平台兼容性。这些本来需要我花上数小时才能做好。

很酷，对吧？

高速之旅

显而易见：AI 让你感觉不可阻挡

• 过去需要一周的项目突然只需两天。
• 摩擦感……消失了。
• 卡在棘手的正则表达式上？AI 能处理。
• 记不起某个库的 API？AI 为你展示。
• 那个让你抓狂的奇怪 bug？AI 提出三种可能的修复方案。

动力才是真正的药剂。你真的把事情做完了。你不会因为遇到瓶颈而半途而废。你发布了东西，感觉良好，然后继续下一个项目。

对于那些被压力和完美主义困扰的人（我有罪），这感觉像是一次革命。

The Downside Appears

A side‑project that turned sour

Two weeks in I shipped a simple tool that pulled data from an API and displayed it nicely. AI had written most of it—API calls, data parsing, error handling, the whole deal.

It worked. I was proud. I moved on.

A week later someone reported a bug: the data wasn’t displaying correctly in a specific case.

I opened the code and stared at it. I realized I had no idea how it worked. I could tell you what it did, but not why it worked that way, nor could I debug it because I didn’t understand the decisions AI had made.

So I did what felt natural—I asked AI to fix the bug. It did. The bug disappeared. But I felt… weird. I’d shipped a fix I didn’t understand, for a project I didn’t understand, to solve a problem I didn’t fully grasp. I was essentially a copy‑paster, but with better branding.

When complexity bites

A month into the experiment I tackled something more complex: multiple files, tricky state management, the kind of thing where small changes have big ripple effects.

Something broke—no clear error, just wrong behavior.

I spent three hours trying to fix it: pasting code into AI, getting suggestions that almost worked but not quite, watching the bug mutate into different bugs, feeling my confidence erode.

The truth about AI:

• It’s great at writing code that works.
• It’s okay at fixing code.
• When you’re deep in the weeds of a complex system you don’t fully understand, AI can’t save you.

Because it doesn’t understand the context either. It doesn’t know the history of decisions you made. It can’t see the system as a whole—it just sees tokens and patterns.

That night, at 2 AM, staring at code I’d technically “written” but didn’t understand, I realized something:

I’d outsourced the thinking, not just the typing.

It’s not just about understanding your code (though that’s huge). It’s about growth.

I looked back at that month of AI‑assisted development and asked myself: “What did I learn?”

The honest answer? Not much.

• I shipped more projects than usual, sure.
• But I hadn’t become a better developer.
• I hadn’t leveled up my problem‑solving.
• I hadn’t really engaged with the interesting parts of the problems I was solving.

I’d become really good at… prompting, assembling pieces, shipping fast.

But the deep satisfaction that comes from genuinely solving a hard problem? That was gone.

And the scary part: I could feel myself getting dependent. I’d start a project and immediately think, “I’ll just have AI handle that part.” I was avoiding the hard stuff—the stuff that actually makes you grow.

对我有效的做法

✅ AI 的良好使用场景

❌ AI 的不良使用场景

我遵循的准则

永不发布你自己无法调试的代码。

在提交 AI 生成的代码之前，我会自问：

1. 我能逐行解释这段代码的作用吗？
2. 我是否明白它为何要这样写，而不是其他方式？
3. 如果它在周日凌晨 3 点出错，我能在没有 AI 帮助的情况下修复吗？

如果对以上任意问题的答案是 “否”， 我就不发布。就这么简单。

具体示例

最近我写了一个 CLI 工具，用来终止在特定端口上运行的进程。很简单。以下是 AI 的帮助方式：

# Prompt to AI
Write a Go CLI that:
- Accepts a port number as an argument
- Finds the PID(s) listening on that port
- Kills those processes (cross‑platform)
- Provides helpful error messages

AI 生成了以下代码：

package main

import (
    "flag"
    "fmt"
    "os"
    "os/exec"
    "runtime"
    "strconv"
    "strings"
)

func main() {
    port := flag.Int("port", 0, "Port number to free")
    flag.Parse()

    if *port  65535 {
        fmt.Println("Please provide a valid port number (1‑65535).")
        os.Exit(1)
    }

    pids, err := findPIDs(*port)
    if err != nil {
        fmt.Printf("Error finding PID(s): %v\n", err)
        os.Exit(1)
    }

    if len(pids) == 0 {
        fmt.Printf("No process is listening on port %d.\n", *port)
        return
    }

    for _, pid := range pids {
        if err := killPID(pid); err != nil {
            fmt.Printf("Failed to kill PID %s: %v\n", pid, err)
        } else {
            fmt.Printf("Killed PID %s listening on port %d.\n", pid, *port)
        }
    }
}

// findPIDs returns a slice of PIDs (as strings) listening on the given port.
func findPIDs(port int) ([]string, error) {
    var cmd *exec.Cmd
    portStr := strconv.Itoa(port)

    switch runtime.GOOS {
    case "windows":
        // netstat -ano | findstr :
        cmd = exec.Command("netstat", "-ano")
    default:
        // lsof -i : -t
        cmd = exec.Command("lsof", "-i", ":"+portStr, "-t")
    }

    out, err := cmd.Output()
    if err != nil {
        // If the command returns a non‑zero exit code but still produces output,
        // we treat the output as valid (e.g., no matches on Windows returns exit code 1).
        if exitErr, ok := err.(*exec.ExitError); ok && len(exitErr.Stderr) == 0 {
            return []string{}, nil
        }
        return nil, err
    }

    // Split output by newlines and trim spaces.
    lines := strings.Split(strings.TrimSpace(string(out)), "\n")
    var pids []string
    for _, line := range lines {
        pid := strings.TrimSpace(line)
        if pid != "" {
            pids = append(pids, pid)
        }
    }
    return pids, nil
}

// killPID attempts to terminate the process with the given PID.
func killPID(pid string) error {
    var cmd *exec.Cmd
    switch runtime.GOOS {
    case "windows":
        cmd = exec.Command("taskkill", "/PID", pid, "/F")
    default:
        cmd = exec.Command("kill", "-9", pid)
    }
    return cmd.Run()
}

我 逐行审查，添加了一些注释，编写了一个小的测试套件，随后才提交。这就是我现在遵循的工作流程。

TL;DR

• AI 可以大幅加速样板代码、调研、解除卡点、审查、测试和文档的编写。
• 它 绝不应取代你对核心逻辑、安全性、性能、架构或生产环境调试的理解。
• 采用个人规则：绝不发布自己无法调试的代码。

把助手当作 合作伙伴，而不是 思考的替代品。 🚀

我从模板中学到的

• 它向我展示了如何通过端口查找进程（这是我以前没有做过的）。
• 它提出了我未曾考虑的跨平台因素。
• 它帮助我编写了有用的错误信息。

我自己做了什么

1. 决定整体结构和流程。
2. 编写核心逻辑（查找进程，安全地终止它）。
3. 手动测试边界情况以了解失败模式。
4. 在提交之前阅读每一行代码。
5. 准备好在有人询问时解释整个程序。

结果: 我在两天而不是五天内完成了它，而且我真的理解了自己构建的内容。

当在 Windows 上报告 bug（自然会出现）时，我准确知道该去哪里查看——无需猜测，也不需要把错误复制粘贴到 AI 中期待奇迹。

当你编码时应该使用 AI 吗？

更好的问题是 你的目标是什么？

• 快速交付一个副项目且不在乎后续增长？
  放手去做。让 AI 完全编写代码，快速上线，观察会发生什么。

• 构建严肃的系统——必须长期可靠，且可能在凌晨 3 点出现生产故障？
  你需要了解自己在构建什么。把 AI 当作 工具，而不是思考的替代品。

• 职业生涯早期，想要成长？
  要小心。没有什么能替代在困难问题中挣扎的过程；正是这种挣扎带来学习。

• 已经有经验，只想提升效率？
  智慧地使用 AI。让它处理低于你技能水平的工作，把精力集中在等同或更高层次的任务上。

我的当前状态（一个月后）

• AI 编写了我约 50‑60 % 的代码。
• 我阅读了 100 % 的代码。
• 我完全理解了 100 % 的代码。
• 如果需要，我可以调试 100 % 的代码。

速度提升和动力依然存在，成长也回来了：解决难题的满足感以及真正理解自己构建的东西所带来的自信。

要点

AI 是一款令人惊叹的工具——也许是我这辈子对开发者生产力影响最大的东西。和任何工具一样，它可以放大你的能力，也可能成为拐杖。区别不在于工具本身，而在于你如何使用它。

• 使用 AI。 接受它，让自己更快、更高效，减少挫败感。
• 永远不要发布你不理解的代码。 未来的你——在凌晨 2 点调试生产问题时——会感谢你的。

你的体验是什么？

你找到适合自己的平衡了吗？我很想听听你的故事。请在下方评论中分享你对 AI 辅助编码的看法！