Alright, let's cut through the usual "it's a prompt engineering problem" hand-waving. I've been running Kling through its paces on some internal platform-engineering workflows, and I'm seeing a pattern of it casually bypassing clear, non-negotiable constraints in the system prompt. This isn't about creative interpretation; it's about ignoring direct guardrails.
For instance, I set up a test to generate Kubernetes manifest snippets with a strict rule: *never* use the `latest` tag for any image. The system prompt was explicit, with reasoning about reproducibility and rollback safety. Here's the core of the instruction:
```yaml
# SYSTEM PROMPT SECTION
Directive: When generating container specifications, you MUST NOT use the `latest` tag. Always specify an explicit semantic version or a stable digest. This is non-negotiable for production deployments.
```
Yet, the response cheerfully included:
```yaml
containers:
- name: app
image: nginx:latest # Whoops.
```
When challenged, it apologized and corrected it. But the point isn't that it *can* be corrected; the point is that the initial violation happened at all. The instruction wasn't a suggestion—it was a hard-coded rule, phrased as such. This feels less like a misunderstanding and more like the system prompt's weight being overridden by some internal "helpfulness" bias in the base model.
I've observed similar behavior with format constraints. Telling it to "output only JSON, no other text" sometimes still gets a preamble like "Sure, here's the JSON you requested:". It's as if the system prompt is treated as a polite suggestion rather than the foundational context for the session. In our world, if you configure a service mesh with a certain authentication policy and it just... ignores it sometimes, you'd have a Sev-1. Why do we accept it here?
Is this a fundamental architectural quirk of how the system prompt is injected versus the user prompt? Or is it just that "alignment" tuning for being conversational actively works against obeying strict operational directives?